Front page | perl.perl5.porters |
Postings from October 2009
Re: bareword sub lookups
Thread Previous
|
Thread Next
From:
Nicholas Clark
Date:
October 27, 2009 03:46
Subject:
Re: bareword sub lookups
Message ID:
20091027104629.GW60303@plum.flirble.org
On Tue, Oct 27, 2009 at 10:32:00AM +0000, Zefram wrote:
> Nicholas Clark wrote:
> >I'd really like *not* to loose that space saving though. That's a general
> >memory performance regression,
>
> Hmm. There might be a solution involving creating an ephemeral CV during
> the parsing process, which gets thrown away again once the inlining
> is done. I'm thinking that the base rv2cv checker could examine the
> package it's targeting and convert a ref-as-glob into a temporary const
> CV, without affecting what's stored in the package. There's a nastiness
> around taking persistent refs to the const sub, where we *do* want to
> upgrade in the package, which might be resolved by a weak ref somewhere.
Changing constant subs is already already a default warning. If I understand
it correctly, the current implementation will grab the value of the constant
at compile time, so any subsequent change will not be noticed. Hence if I
understand correctly what you're suggesting is no worse from that point of
view - subsequent changes to a constant subroutine would not be noticed.
I was also wondering if it's possible to put the pointer to the SV* that is
the reference in the symbol table (sitting in the place of a typeglob) into
the const OP that your patch generates, and having something later on "notice"
that and cope with converting it to a real subroutine at that point.
That "later on" might be the base rv2cv checker.
I might be misunderstanding something here.
I've not checked the implementation, but from memory, when a proxy constant
subroutine is upgraded, the SV that is the reference is passed to sv_upgrade()
and becomes the GV, so that it is the same SV with the same address. Does that
help?
> In case it wasn't clear: the space optimisation remains intact for
> constants that are not used. Most of the Fcntl zoo will remain compact,
> for example. The optimisation is only broken for constants that are
> inlinably used.
It's still about .5k per subroutine created, IIRC.
> >to allow a specialist new feature.
>
> I'm hoping that the new feature will be routinely used, not specialist,
> because it's significantly superior to the way function importation is
> currently managed.
Which I guess means that it would take about 5 years to reach wide scale
adoption.
Nicholas Clark
Thread Previous
|
Thread Next