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