Front page | perl.perl5.porters |
Postings from January 2010
Re: [patch 0/3] rework sv.c body-inventory mechanics
Thread Previous
|
Thread Next
From:
Jim Cromie
Date:
January 31, 2010 10:23
Subject:
Re: [patch 0/3] rework sv.c body-inventory mechanics
Message ID:
cfe85dfa1001311023m4fa5290aoe30c94d1edfebf14@mail.gmail.com
On Sat, Jan 30, 2010 at 9:51 AM, Reini Urban <rurban@x-ray.at> wrote:
> 2010/1/30 Nicholas Clark <nick@ccl4.org>:
>> On Wed, Jan 27, 2010 at 06:30:09PM -0700, Jim Cromie wrote:
>>> these patches add a request-id to the body-parts allocation chain
>>> ie to:
>>> new_body, del_body macros,
>>> S_more_bodies()
>>> get_arena()
>>>
>>> In principle, this change will allow perl to track
>>> each user of get_arena(), such that we can (later) reclaim it.
>>
>> I'm really not sure what outstanding problem this is solving.
>> It seems to add complexity, rather than simplifying.
>
> Sure. There's one more tag per body.
To be more precise, theres an additional param in the
body-parts allocation chain (3 calls), but no added fields in an SV.
This will have some small increased cost, 99% of it residing
in the (new|del)_body.* macros, S_more_bodies and get_arena
are called ~1000x less often.
> But as I understand it, Jim wants to improve the performance of
> release_arenas().
You've come to the crux of it.
release_arenas() doesnt actually exist now, so its performance is
arguably zero, hopefully going to 1 soon.
> I'm dying to see the new release_arenas() code and the benchmark.
benchmarking presents some problems; its very much like
benchmarking a program with PERL_DESTRUCT_LEVEL=2 vs 0,
there will be a cleanup cost in the former thats not seen in the latter.
the real issue is what new features it may support:
- early reclaim of PTEs.
When Storable::freeze() is used to create ~/.cpan/Metadata,
~2**19 (iirc) PTEs are created, then freed back to PL_bodyroots[x],
but this free-list hangs out til process termination.
Surely we have better things to do with that memory than
to save it JUST IN CASE we need to freeze another dataset.
- segregated allocation
Tim Bunce was recently asking for private-arenas to support NYTProf.
My view is you dont really have a proper private-arenas facility
until you can recycle them.
Conceivably, a routine populating a data structure could push
fresh/empty freelists into the interpreter, and then
all allocations made by the routine or its callees would be made from
known arenas. In the extreme case,
the sv-typed arenas could be sized such that ALL allocs
done in the routine would fit in one arena each.
This could be useful in somewhat esoteric situations.
- use less memory
early PTE cleanup qualifies as one tool with benefits
here.
> --
> Reini Urban
> http://phpwiki.org/ http://murbreak.at/
>
Thread Previous
|
Thread Next