
"M.-A. Lemburg" <mal@lemburg.com> writes:
My conclusion? Python 2.1 is slower than Python 2.0, but not by enough to care about.
What compiler did you use and on which platform ?
Argh, sorry; I meant to put this in! $ uname -a Linux atrus.jesus.cam.ac.uk 2.2.14-1.1.0 #1 Thu Jan 6 05:12:58 EST 2000 i686 unknown $ gcc --version 2.95.1 It's a Dell Dimension XPS D233 (a 233MHz PII) with a reasonably fast hard drive (two year old 10G IBM 7200rpm thingy) and quite a lot of RAM (192Mb). [snip]
AFAIR, Vladimir's malloc implementation favours small objects. All number objects (except longs) fall into this category.
Well, longs & complex numbers don't do any free list handling (like floats and int do), so I see two conclusions: 1) Don't add obmalloc to the core, but do simple free list stuff for longs (might be tricky) and complex nubmers (this should be a no-brainer). 2) Integrate obmalloc - then maybe we can ditch all of that icky freelist stuff.
Perhaps we should think about adding his lib to the core ?!
Strikes me as the better solution. Can anyone try this on Windows? Seeing as windows malloc reputedly sucks, maybe the differences would be bigger. Cheers, M. -- Our lecture theatre has just crashed. It will currently only silently display an unexplained line-drawing of a large dog accompanied by spookily flickering lights. -- Dan Sheppard, ucam.chat (from Owen Dunn's summary of the year)