Front page | perl.perl5.porters |
Postings from November 2012
---------------------------------------- > Date: Thu, 1 Nov 2012 09:33:41 +0100 > Subject: Re: Eliminating the "rehash" mechanism for 5.18 > From: demerphq@gmail.com > To: bulk88@hotmail.com > > Did you mean this to be offlist? No. That was an accident. > > On 1 November 2012 09:09, bulk 88 <bulk88@hotmail.com> wrote: > > > > > > > > There are multiple objectives. I had hoped to see a performance boost. I just hope the replacement implementation will not be a performance decrease. > As far as I can tell that would still work. In fact it seems to me > like things would be better to some degree, as there would be no more > "two hashes" and the difference between PERL_HASH() and > PERL_HASH_INTERNAL_() would be eliminated (and actually > PERL_HASH_INTERNAL_() just goes away). The difference between the 2 macros is just where the hash key is obtained from, "U32 hash_PeRlHaSh = (internal ? PL_rehash_seed : PL_hash_seed);" which is constant folded away for PERL_HASH to PL_hash_seed. > The thing is the layout would be different process to process, but not > internally to a process. That is fine for me. My unpublished code studies and remembers the positions in the array and linked list of the hash elements at runtime. > > On the other hand if we ever introduced per-hash hashing, (as a > security measure) then it would break. Or we would have to give you a > way to control it, or something. I'm hoping we don't need per-hash > hashing if we have random hash seeding. I could imagine restricted hashes having a per restricted hash hash that guarentees no keys collide and that all those keys are accessed through array alone, no linked list. Or maybe a future linked-list-less hash api where reads and replace are cheaper than current hash api but inserts are very costly.Thread Previous | Thread Next