develooper Front page | perl.perl5.porters | Postings from October 2016

Re: hv.h hek definition

Thread Previous | Thread Next
From:
bulk 88
Date:
October 25, 2016 20:38
Subject:
Re: hv.h hek definition
Message ID:
CY4PR04MB0663B5E1D2F192945EE50B47DFA80@CY4PR04MB0663.namprd04.prod.outlook.com
Dave Mitchell wrote:
> I ran the following code:
> 
>     my %h;
>     @h{aa..zz} = ();
>     my $x;
>     $x = $h{aasnstnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnn} for 1..10_000_000;
> 
> However, this may well be different on RISC systems which have strict
> alignment constraints (ARM??).
> 
> Note that in the COW implementation, FC put the COW refcount at the end of
> the string for similar alignment reasons.
> 
> I've had a vague idea at the back of my mind for a while that it might be
> worth pre-allocating PVX buffers with N leading bytes (and SvOOK set),
> where those N bytes are used to store the COW ref count. They could also
> then be used as part of the HEK structure too. The size of N would depend
> on the platform and alignment constraints, but might be 4 or 8. This
> would add an extra memory overhead for strings, but in practice malloc()
> libraries over allocate anyway (for example on my Linux system,
> malloc/realloc returns (IIRC) 24+16n sized blocks, so strings with length
> 0..16 would be unaffected, strings of length 17..24 would use an extra 16
> bytes, lengths 25..32 unaffected. and so on).
> 
> But this is just a vague bit of handwaving.
> 

Every byte counts. It takes 1 byte to spill the malloc allocation into 
the next bucket.  Bucket sizes (you mentioned yours increase in units of 
16 bytes) are highly OS and OS release specific. Hash keys aren't all 
going to be powers of 2 strings, or /2 or /4 or /8 long. What about the 
null byte at the end of the hash key? etc. Dont over allocate if you can 
help it.

Thread Previous | Thread Next


nntp.perl.org: Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at ask@perl.org | Group listing | About