Front page | perl.perl5.porters |
Postings from January 2001
On Wed, Jan 17, 2001 at 11:25:21PM +0000, nick@ing-simmons.net wrote:
> Nicholas Clark <nick@ccl4.org> writes:
> >On Sat, Jan 13, 2001 at 09:21:09AM -0700, Nathan Torkington wrote:
> >> - work out how to precalculate the hash values for things like
> >> UNIVERSAL and main:: and other commonly hashed strings, and see
> >> what kind of performance win results (if any)
> >
> >Did anyone on here suggest storing the computed hash key for a SV in the
> >IV slot (in the same way that SVf_OOK stores the offset)? Or is my memory
> >deceiving me?
>
> There is a special "shared" SV which has SvFAKE_on and SvREADONLY.
> It does that, but _also_ has SvPVX pointing to shared string in shared key
> table. Thus when doing a hash lookup we compare SvPVX before doing strcmp().
I can find how the code to chose between sharing and not sharing the key
(for example)
if (HvSHAREKEYS(hv))
HeKEY_hek(entry) = share_hek(key, is_utf8?-klen:klen, hash);
else /* gotta do the real thing */
HeKEY_hek(entry) = save_hek(key, is_utf8?-klen:klen, hash);
I can't see strcmp()s being avoided with SvPVX comparison - where should
I be looking?
> >Either way, is it OK to meddle with the IV slot on a SV with SVf_READONLY set?
>
> In general it is not safe. But making more use of 'shared' SVs for string
> litterals will help. sv.c etc. has been taught about those and can cope.
>
> >Is it a sign that the value isn't mutable? Or that it's to be treated as if
> >it's in read only memory?
>
> The snag is IV slot may be in use for real, or abused for something already.
I think it can only be used for real or for the offset for SvOOK. And
as there's already this overloading, code wanting to set the IVX is
(or should be or it will have triggered bugs long ago) calling
Sv_IOK_on first (to ensure SvOOK_off() is off). Modifications to the
Sv_IOK_on and SvOOK code should be all that would be needed. I don't
think that this would be anywhere near as bad as trying to overload
the NV slot.
Nicholas Clark
Thread Previous
|
Thread Next