Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

Comparing perl and python

1 view
Skip to first unread message

Tim Roberts

unread,
Feb 23, 2000, 3:00:00 AM2/23/00
to
I've been reading this newsgroup for a couple of weeks, and I'm a bit
afraid my subject line might label me as a troll, but as a python newbie,
it is one which interests me.

I've done a couple of projects in python as a way of learning it, including
some text processing and a couple of CGI scripts. Thus far, I find I
prefer the python syntax to perl; I think it makes for
easier-to-read-programs. Further, although it might be more related to the
way I learned perl, I find that perl tends to encourage monolithic
programs, whereas python seems to lend itself more easily to a more
modularized structure. These are both Good Things.

It's clear that there is a substantial library of modules for python,
approaching that of perl. However, I am disturbed by what seems to be a
dramatic performance difference. I've tried writing some simple test cases
in both languages, and I'm finding python to be 2x, 3x, and in one case 12x
slower than the equivalent program in perl. (The 12x case was a simple
"grep the files in stdin", using the "re" and "multifile" modules in
python.)

Now, it's possible this is just because python is version 1.6 and perl is
version 5; maybe python hasn't had the attention to optimization that perl
has, but I'd like to know if my experiences are unique. Have others done
such comparisons?
--
- Tim Roberts, ti...@probo.com
Providenza & Boekelheide, Inc.

Aahz Maruch

unread,
Feb 23, 2000, 3:00:00 AM2/23/00
to
In article <his6bs08biqdkasl8...@4ax.com>,

Tim Roberts <ti...@probo.com> wrote:
>
>It's clear that there is a substantial library of modules for python,
>approaching that of perl. However, I am disturbed by what seems to be a
>dramatic performance difference. I've tried writing some simple test cases
>in both languages, and I'm finding python to be 2x, 3x, and in one case 12x
>slower than the equivalent program in perl. (The 12x case was a simple
>"grep the files in stdin", using the "re" and "multifile" modules in
>python.)

In raw speed, Perl tends to run about twice as fast for the most
"obvious" way to do things. This advantage spreads to 5x or 10x when
you talk about the "obvious" way to do certain kinds of I/O.

The advantage diminishes rapidly when you compare the code of expert
programmers, and it mostly vanishes when you start looking at real,
complex programs. Main reason for that is that Python code is so much
easier to write, you spend more time looking at the algorithms -- that's
where you get your order of magnitude increases in performance.

Remember that Perl is optimized to be a "super AWK". And IMO, that's
about all it's good for.
--
--- Aahz (Copyright 2000 by aa...@netcom.com)

Androgynous poly kinky vanilla queer het <*> http://www.rahul.net/aahz/
Hugs and backrubs -- I break Rule 6

Love does not conquer all. Humans are extremely flexible, usually more
flexible than we're willing to admit. But some flexibility comes at a
cost, and sometimes that cost is more than we can bear.

François Pinard

unread,
Feb 23, 2000, 3:00:00 AM2/23/00
to Tim Roberts
Tim Roberts <ti...@probo.com> writes:

> I am disturbed by what seems to be a dramatic performance difference

> [between Perl and Python...] Have others done such comparisons?

Just a few months ago, I was also a complete newbie, and has also been
worried by speed differences, the same as you do now, and raised the matter
on that discussion list. Most certainly, others did before me :-).

My first attempts at writing Python were much tainted with Perl style, and
had to discover that you have to learn a few Python idioms to get more speed.
More generally, Python gives you more control than Perl on details, but
you have to be a bit more careful at details as well. For example, Perl
has a lot of optimisation work put on regular expressions and input/output,
some say insane optimisation :-). Python has a more relaxed implementation
of both, and we have to learn to avoid using regular expressions everywhere
and all the time, and learn to bunch input/output more than we do in Perl.
In a word, you have to learn to compensate a bit, with better algorithms.
This is usually easy, because of the gain in clarity you've already got.

This comes with experience, I guess. This mailing list is also a very
good resource. I do not notice speed differences as much as when I began to
write Python, but I feel I write in a more Pythonic than Perlish style now.
Speed differences might still exist, but not enough to be really bothering.
The advantages of Python, for me, overcome some inherent slowness at
times, yet my feeling is that Python speed is quite reasonable on average.
It is probably that my first experiments were lacking a bit, style-wise.

P.S. - I've now written well over 20000 lines of Python, and continuing.
I feel a bit more solid than I was initially :-). Strangely, I'm not in
a hurry to use every feature available. I'm quite satisfied with simplicity.

--
François Pinard http://www.iro.umontreal.ca/~pinard


Bill Tutt

unread,
Feb 23, 2000, 3:00:00 AM2/23/00
to Mridul, Python Mailing List

> From: Mridul [mailto:mri...@newgen.co.in]

> Here's something to chew on as far as speed is concerned:
>
> Python2C
> More recently, Bill Tutt and Greg Stein developed Python2C. This
> translates Python to C code. Mostly, the C code ends up
> manipulating
> PyObjects in much the same way as if you had recreated
> the Python code
> in C using the high level Python / C API. That is, you'll
> get a speed
> up from the fact that there's no byte-code interpreter loop, but
> that's less than most people expect. (There's been a lot
> of talk about
> global program analysis and type deduction. When these ideas bear
> fruit, more dramatic speed ups will become possible.)
>

Its available from http://lima.mudlib.org/~rassilon/p2c.
However I wouldn't recommend its use in production code as of yet. There are
still some serious known outstanding bugs that need to get fixed.
(Including the fact that I can't debug p2c itself in MSVC due to a debug
symbol limit)

If you'd like to help by working on the code that is always appreciated
since my time on the project is limited due to this annoying thing called
fulltime work.

Bill


Thomas A. Bryan

unread,
Feb 23, 2000, 3:00:00 AM2/23/00
to
Tim Roberts wrote:
>
> I've been reading this newsgroup for a couple of weeks, and I'm a bit
> afraid my subject line might label me as a troll, but as a python newbie,
> it is one which interests me.

It's not so bad as long as you don't cross-post to comp.lang.perl.misc.

> Further, although it might be more related to the
> way I learned perl, I find that perl tends to encourage monolithic
> programs, whereas python seems to lend itself more easily to a more
> modularized structure. These are both Good Things.

I found the same thing. When I learned Python, I only knew C and Perl.
After programming in Python for a few months, my coding got better not
just in Python, but also in C and Perl. Using Python for a year also
made it much easier to pick up C++ and Java later.

> It's clear that there is a substantial library of modules for python,

> approaching that of perl. However, I am disturbed by what seems to be a
> dramatic performance difference.

Search DejaNews for comp.lang.python threads involving performance, Python,
and Perl. You'll find quite a few. Python tends to be slower than Perl
in the problem domains where Perl really shines. Most people who start
such threads are recovering Perl hackers who are writing Python in a
Perl idiom. For example, Perl's regular expressions are really fast.
People use them all the time to fairly trivial work. When rewriting a
Perl program in Python, I find that I can often replace half of the
regular expressions by using the string and os.path modules in Python.
That helps speed.

> I've tried writing some simple test cases in both languages....

If you try to directly translate, you'll almost certainly notice a
speed hit. To phrase it poorly ;-)
"Important note: Python programs that aren't very Pythonish tend
to run much slower than the Pythonish ones. "

It's from a page of mine that I haven't touched recently:
http://starship.python.net/~tbryan/perl2python.html

You might be interested in looking through the one sample that I
documented. I'll do others once I have spare time again.

> Now, it's possible this is just because python is version 1.6 and
> perl is version 5; maybe python hasn't had the attention to
> optimization that perl has,

Python has been around for a long time. The version numbers creep
forward slowly, but there are huge differences between versions
1.3 and 1.5. That said, Python is never going to be optimized
for input and text processing in the same way that Perl has been
unless some skilled volunteer or company provides a patch that
implementes such optimizations and doesn't break anything else.

> but I'd like to know if my experiences are unique.

No. As I said, look at DejaNews. Then again, you'll often notice
that the messages posted with code examples were trimmed and
rewritten by comp.lang.python posters. Often performance differences
can be reduced to a factor of 2 just by ridding the program of
Perl idioms and avoiding slower Python modules. Not infrequently, we're
able to create a Python program that performs the same task as the
initial Perl program that someone is trying to mimic. Really, read a
few threads on DejaNews if you're very concerned. It should give
some good ideas. The topic comes up every few months.

---Tom

Nathaniel Gray

unread,
Feb 23, 2000, 3:00:00 AM2/23/00
to
If regexes are your concern, you may not need to worry much longer. The
regular expression engine for Python 1.6 should be significantly faster
than the current one.

Here are some benchmarks that Fredrik Lundh posted to c.l.p. last month:

0 5 50 250 1000 5000 25000
----- ----- ----- ----- ----- ----- ----- -----
search for Python|Perl in Perl ->
sre8 0.007 0.008 0.010 0.010 0.020 0.073 0.349
sre16 0.007 0.007 0.008 0.010 0.020 0.075 0.353
re 0.097 0.097 0.101 0.103 0.118 0.175 0.480
regex 0.007 0.007 0.009 0.020 0.059 0.271 1.320

search for (Python|Perl) in Perl ->
sre8 0.007 0.007 0.007 0.010 0.020 0.074 0.344
sre16 0.007 0.007 0.008 0.010 0.020 0.074 0.347
re 0.110 0.104 0.111 0.115 0.125 0.184 0.559
regex 0.006 0.006 0.009 0.019 0.057 0.285 1.432

search for Python in Python ->
sre8 0.007 0.007 0.007 0.011 0.021 0.072 0.387
sre16 0.007 0.007 0.008 0.010 0.022 0.082 0.365
re 0.107 0.097 0.105 0.102 0.118 0.175 0.511
regex 0.009 0.008 0.010 0.018 0.036 0.139 0.708

search for .*Python in Python ->
sre8 0.008 0.007 0.008 0.011 0.021 0.079 0.379
sre16 0.008 0.008 0.008 0.011 0.022 0.075 0.402
re 0.102 0.108 0.119 0.183 0.400 1.545 7.284
regex 0.013 0.019 0.072 0.318 1.231 8.035 45.366

search for .*Python.* in Python ->
sre8 0.008 0.008 0.008 0.011 0.021 0.080 0.383
sre16 0.008 0.008 0.008 0.011 0.021 0.079 0.395
re 0.103 0.108 0.119 0.184 0.418 1.685 8.378
regex 0.013 0.020 0.073 0.326 1.264 9.961 46.511

search for .*(Python) in Python ->
sre8 0.007 0.008 0.008 0.011 0.021 0.077 0.378
sre16 0.007 0.008 0.008 0.011 0.021 0.077 0.444
re 0.108 0.107 0.134 0.240 0.637 2.765 13.395
regex 0.026 0.112 3.820 87.322 ...

search for .*P.*y.*t.*h.*o.*n.* in Python ->
sre8 0.010 0.010 0.014 0.031 0.093 0.419 2.212
sre16 0.010 0.011 0.014 0.030 0.093 0.419 2.292
re 0.112 0.121 0.195 0.521 1.747 8.298 40.877
regex 0.026 0.048 0.248 1.148 4.550 24.720 ...

(searching for the given patterns in strings padded
with blanks on both sides. sre8 is the new python
1.6 engine on 8-bit strings, sre16 is the same engine
using unicode)

--
Nathaniel A. Gray
--
"But the sun is going down!"
"No, no, you're all confused. The horizon is moving up."
-The Firesign Theatre
--
PGP Key:
http://certserver.pgp.com:11371/pks/lookup?op=get&search=0x95345747
For PGP: http://www.pgpi.com/

François Pinard

unread,
Feb 24, 2000, 3:00:00 AM2/24/00
to Charles Cazabon
c_ca...@hotmail.com (Charles Cazabon) writes:
> Aahz Maruch claimed in <88vtfj$egl$1...@nntp6.atl.mindspring.net>:

> >Remember that Perl is optimized to be a "super AWK". And IMO, that's
> >about all it's good for.

> Best description I ever heard was "`sed' on crack".

Even if I am a Python lover now, I'm a previous Perl addict, and Perl was
not that bad[1]. So, even if humorous, such judgements are derogative
and unfair, and we should stay more open minded.

Perl is used for a wide variety of applications. It has a lot of dedicated
contributors, a good organisation, to the point it is undoubtly a social
phenomenon in itself. We should at least recognise these facts, and
even copy the good parts. Larry Wall is absolutely overwhelmed by now,
but at a time he was more accessible, I found him to be a very attaching
and charismatic guy. However, I would not say that much from his troops,
who quite destroyed the initial spirit, in my opinion. Sad for Larry...

I just hope that Python will learn from, and avoid Perl social mistakes.
That would not be an easy challenge, if Python starts growing too fast...

--------------------
[1] It's just that Python is better! :-).

Tim Peters

unread,
Feb 24, 2000, 3:00:00 AM2/24/00
to pytho...@python.org
[Aahz Maruch[
> Best description I ever heard [of Perl] was "`sed' on crack".

[François Pinard]


> Even if I am a Python lover now, I'm a previous Perl addict, and Perl was
> not that bad[1]. So, even if humorous, such judgements are derogative
> and unfair, and we should stay more open minded.

No way -- this newsgroup has a Zero Tolerance policy for drugs <wink>.
Frankly, I expect Larry Wall would be tickled by the "sed on crack"
description. Just as Guido would be by calling Python "Perl on Thorazine".

> ...
> I just hope that Python will learn from, and avoid Perl social mistakes.
> That would not be an easy challenge, if Python starts growing too fast...

Well, c.l.py has high tolerance for bad taste, even extending to humorous
wordplay that can be perceived as derogative and unfair (Monty Python would
approve). It has low tolerance for flaming, though, and that appears to be
key. People withdraw from overly contentious threads here just a tad or two
beyond the point where they *start* becoming flamewars, letting them die or
moving them off the group. Doesn't hurt to remember that everyone was a
newbie once, too.

c.l.py-is-c.l.p.m-on-quaaludes-ly y'rs - tim


Ivan Van Laningham

unread,
Feb 24, 2000, 3:00:00 AM2/24/00
to Python Mailing List
Hi All--

Tim Peters wrote:
>

[bobbit]

> c.l.py-is-c.l.p.m-on-quaaludes-ly y'rs - tim
>

<i-guess-that-makes-us-all-'ludesers>-ly y'rs,
Ivan
----------------------------------------------
Ivan Van Laningham
Callware Technologies, Inc.
iva...@callware.com
http://www.pauahtun.org and
http://www.foretec.com/python/workshops/1998-11/proceedings.html
Army Signal Corps: Cu Chi, Class of '70
Author: Teach Yourself Python in 24 Hours


0 new messages