74 lines
2.7 KiB
Plaintext
74 lines
2.7 KiB
Plaintext
From: tismer at appliedbiometrics.com (Christian Tismer)
|
|
Date: Fri, 07 May 1999 17:20:57 +0200
|
|
Subject: Python IS slow ! [was] Re: Python too slow for real world
|
|
References: <000401be9831$a0ac04c0$979e2299@tim>
|
|
Message-ID: <373304D9.65EA0AD6@appliedbiometrics.com>
|
|
Content-Length: 2445
|
|
X-UID: 1790
|
|
|
|
|
|
Tim Peters wrote:
|
|
>
|
|
> [various, about malloc/free performance]
|
|
>
|
|
> [Christian Tismer]
|
|
> > ...
|
|
> > A malloc just for Python - would it need locking at all?
|
|
> > Since the interpreter is locking already, I guess malloc
|
|
> > would be always called in a safe way.
|
|
>
|
|
> Right. Note that Vladimir has already put a great deal of work into this
|
|
> area; see
|
|
>
|
|
> http://starship.python.net/crew/vlad/pymalloc/
|
|
>
|
|
> IIRC, paradoxically this yielded bigger speedups on non-Windows systems.
|
|
>
|
|
> windows-vm-flushes-most-recently-used<0.9-wink>-ly y'rs - tim
|
|
|
|
Thanks a lot. Now I have so many ways to go that I cannot
|
|
decide. Vlad uses explicit bins, dedicated storage. While
|
|
this can be very fast, it is a generalization of Guido's
|
|
pre-allocated arrays for some kinds of objects. Nobody
|
|
can tell me if this is the way to go, or if it will
|
|
under circumstances yield much fragmentation. Doug Lea's
|
|
code is more general, since his bins are linked lists of
|
|
free space which can coalesce again. Takes more time and
|
|
less fragmentation. And J.C. Wippler gave me a very fast
|
|
allocator for small objects which uses a power of two
|
|
size scheme, with memory blocks arranged in a way that
|
|
their size is encoded in the address (portable!).
|
|
|
|
I guess finding out "the right way"(TM) is NP-complete.
|
|
|
|
If I knew in advance how long certain objects will live,
|
|
then I would be able to put them into the proper place.
|
|
Does it make sense to do statistics on object lifetime?
|
|
But the only known thing is allocation size.
|
|
|
|
Also, Python knows a lot more than malloc: A list(dict)
|
|
is always two things: A header which cannot move, and
|
|
a body which can move and grow and shrink. Could make
|
|
sense to use different strategies for heads and bodies.
|
|
Bad again with strings and tuples which have varying
|
|
size and are not moveable. I would be much happier if
|
|
we would pay the one level of indirection, but we
|
|
had all the varying sizes moveable, since this would
|
|
allow for some compaction as well.
|
|
|
|
But I know it is too late :-)
|
|
|
|
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
|
|
|
|
|
|
|
|
|