Home Original page

why python is slower than java?

Alex Martelli aleaxit at yahoo.com
Sun Nov 7 09:04:28 EST 2004 
Roy Smith <roy at panix.com> wrote:

> Terry Hancock <hancock at anansispaceworks.com> wrote:
> > And I have certainly written some extremely poorly optimized
> > Python programs that positively *crawled*.
> 
> My guess is the poor performance had nothing to do with the language you
> wrote it in, and everything to do with the algorithms you used.

I think this is an overbid.

> Local optimizations rarely gets you more than a factor of 2 improvement.
> Choice of language (at least within the same general catagory such as
> comparing one native compiled language to another, or one virtual 
> machine language to another) probably has a somewhat broader range, but
> still a factor of 10 would be quite surprising.

kallisti:/tmp alex$ python -mtimeit 'exec("x=2")'
10000 loops, best of 3: 64.7 usec per loop
kallisti:/tmp alex$ python -mtimeit 'x=2'
10000000 loops, best of 3: 0.187 usec per loop

There: a factor of 350 just for using the wrong construct in the same
language -- a silly exec rather than a plain assignment.

 
> To get really bad performance, you need to pick the wrong algorithm.  A
> project I worked on a while ago had a bit of quadratic behavior in it
> when dealing with files in a directory.  Most of our customers dealt 
> with file sets in the 100's.  One customer had 50,000 files.  Going 
> from, say, 500 to 50,000 is a 100-fold increase in N, and gave a 
> 10,000-fold increase in execution time.

Right, big-O can often dominate (there are exceptions: in almost all
practical cases the outstanding performance of Python's list.sort wipes
away the theoretical issue that it's O(N logN), letting dominate for
many special cases approaches that are O(N) -- the multiplicative
constants differ by just TOO much for all practically usable N's!-).

Still, consider...:

kallisti:/tmp alex$ python -mtimeit 's=[]
for x in xrange(1000): s = s+[x]'
100 loops, best of 3: 13.7 msec per loop

kallisti:/tmp alex$ python -mtimeit 's=[]
for x in xrange(1000): s += [x]'
1000 loops, best of 3: 1.58 msec per loop

The difference between s += [x] and s = s + [x] is large.  AND:

kallisti:/tmp alex$ python -mtimeit 's=[]
for x in xrange(4000): s = s+[x]'
10 loops, best of 3: 224 msec per loop

kallisti:/tmp alex$ python -mtimeit 's=[]
for x in xrange(4000): s += [x]'
100 loops, best of 3: 6.4 msec per loop

...the big-O is different!!!  O(N) for +=, way bigger for plain +: as
you can see, a x4 on N makes a 16.3 times increase in time here,
suggesting AT LEAST quadratic behavior.  Again, these are good vs bad
cases in the *same* language - Python 2.4 beta 1 in all cases.  I'm sure
you can easily imagine how different languages might make apparently
identical constructs be O(N) vs O(N squared) or worse, if even the same
language can do so for constructs whose difference may not be apparent
at all to the newbie...


Alex
More information about the Python-list mailing list