RetroSearch Browse

Mon Nov 3 09:58:34 EST 2003 · https://mail.python.org/pipermail/python-dev/2003-November/039910.html

Hello Martin,

On Mon, Nov 03, 2003 at 01:18:53AM +0100, "Martin v. L?wis" wrote:
> >"Not easy" would have been more appropriate.  It is still basically what
> >malloc() does.
> 
> That's why I said "efficient". What malloc basically does is not 
> efficient. It gets worse if, at reallocation time, you are not only 
> bound by size, but also by type. E.g. if you have deallocated a tuple of
> 10 elements, and then reallocate a tuple of 6, the wasted space can only
> hold a tuple of 1 element, nothing else.

That's why we have a custom allocator in Python, to minimize this kind of
impact by subdividing arenas into pools of objects grouped by size.  I admit
that adding the type constrain adds burden to the allocator, though.

> So where do you put strings with 100,000 elements (characters)? Or any 
> other object that exceeds an arena in size?

These ones are not a problem, because objects and arena can be larger than the
MASK.  You get to the start of the arena by masking bits away from the address
of the *beginning* of the object.  An arena can be of any size as long as all
the objects it contains starts in the first MASK bytes.  For a very large
object, the arena would contain only this object, which would then start at
the beginning of the arena.

I'm more concerned about medium-sized objects, e.g. the ones whose size is 51%
of MASK.  At the moment I don't see a good solution for these.

A bientot,

Armin.

Home - News ( United States | United Kingdom | Italy | Germany ) - Football scores

Showing content from https://mail.python.org/pipermail/python-dev/2003-November/039910.html below:

[Python-Dev] Looking for master thesis ideas involving Python