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

[Christian Tismer]

Guido van Rossum wrote:
> 
> Christian Tismer <tismer at appliedbiometrics.com> writes:

[a little Windoze timing]

> > 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 :-)

I don't like to pull a GNU licensed thing into Python.
Further, I did statistics on the malloc calls for
pystone and Idle, and it turns out that 99 percent
of all mallocs in a typical Python program are of
a size upto 128 bytes.
Therefore, my malloc will only handle these cases
in a very fast way, and redirect all other allocations
(including its own buffers) to the original
malloc function, which may spend the time it needs
for the one percent of cases.

This can be nearly equally as fast as your extra code
for ints, frames and small tuples.
I'm going to gather it.

ciao - chris

-- 
Christian Tismer             :^)   <mailto:tismer at appliedbiometrics.com>
Applied Biometrics GmbH      :     Have a break! Take a ride on Python's
Kaiserin-Augusta-Allee 101   :    *Starship* http://starship.python.net
10553 Berlin                 :     PGP key -> http://wwwkeys.pgp.net
PGP Fingerprint       E182 71C7 1A9D 66E9 9D15  D3CC D4D7 93E2 1FAE F6DF
     we're tired of banana software - shipped green, ripens at home