[M.-A. Lemburg]
> AFAIR, Vladimir's malloc implementation favours small objects.
It favors the memory alloc/dealloc patterns Vlad recorded while running an
instrumented Python. Which is mostly good news. The flip side is that it
favors the specific programs he ran, and who knows whether those are
"typical". OTOH, vendor mallocs favor the programs *they* ran, which
probably didn't include Python at all <wink>.
> ...
> Perhaps we should think about adding his lib to the core ?!
It's patch 101104 on SF. I pushed Vlad to push this for 2.0, but he wisely
decided it was too big a change at the time. It's certainly too much a
change to slam into 2.1 at this late stage too. There are many reasons to
want this (e.g., list.append() calls realloc every time today, because,
despite over-allocating, it has no idea how much storage *has* already been
allocated; any malloc has to know this info under the covers, but there's no
way for us to know that too unless we add another N bytes to every list
object to record it, or use our own malloc which *can* tell us that info).
list.append()-behavior-varies-wildly-across-platforms-today-
when-the-list-gets-large-because-of-that-ly y'rs - tim
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4