Python IS slow ! [was] Re: Python too slow for real world

Guido van Rossum guido at eric.cnri.reston.va.us
Thu May 6 08:42:26 EDT 1999


Christian Tismer <tismer at appliedbiometrics.com> writes:

> This is all wonderful stuff. But I think we are 
> missing one point, and if I didn't go completely nuts
> last night, there might be some fairly low hanging
> fruit which could save 30% of runtime, at least speaking of NT.

> Test 1: Running python.exe with the commandline
> -c "from test.pystone import *;map (lambda x:main(), range(10))"
> 
> Result time: 22.36% malloc, 14.35% free.
> 
> Test 2: Running pythonw.exe and Idle, and removing again
> all system calls and Tcl/Tk calls, just keeping the two dlls as
> above:
> 
> Result time: 19.47% malloc, 12.29% free.
> 
> Which tells me that if we could avoid most of these calls
> and provide a very fast allocation scheme for small blocks,
> I believe a single extension module would gain 25% of win!

You call avoiding malloc() and free() low-hanging fruit?  You must be
deluded <0.5 wink>.  All the low-hanging fruit has already been
picked: special allocation strategies for ints, frames, even small
tuples!  You could try linking in GNU malloc and see if it's faster
than native malloc -- now *that* is low-hanging fruit.  (GNU malloc
has a reputation for being the fastest malloc arround; Microsoft's
doesn't :-)

--Guido van Rossum (home page: http://www.python.org/~guido/)




More information about the Python-list mailing list