The performance of the blessed hash case is dependent on the length of the keys used in the hash: The longer the key, the more time it takes!

For one-character keys, blessed hashes are slightly faster than the cached refaddr case. (I got 2% when I did the timings.) However, one-character keys are rather unrealistic, and definitely not good programming practice.

For two-character keys, the performance is the same.

For three or more characters, cached refaddr is faster! I think five characters is realistic, and their performance is 2% slower. For ten characters, 7% slower!

So if I were to call a winner, cached refaddr would be it.

On another minor note, 0+$self yields the same result as the refaddr function. So you can eliminate 'use Scalar::Util', and just cache 0+$self.

I'm a little surprised at the refaddr versus 0+$self conclusion, though -- I would have thought that refaddr is just XS that returns a memory address, whereas 0+$self would wind up casting things to Perl scalars with associated overhead. I guess it's optimized away. Good to know.

-xdg

Code written by xdg and posted on PerlMonks is public domain. It is provided as is with no warranties, express or implied, of any kind. Posted code may not have been tested. Use of posted code is at your own risk.

Even more efficient would be to write a custom hash loading routine in XS that a) extracts the refaddr automatically, and b) uses the binary representation of the address as the key for the hash lookup/storage. Currently when you use $hash{0+$self}=$foo you are doing itoa() on the address, then using the resulting string for the hash key. If the addresses binary representation was used as the key they keys would be fixed length, and would not require the itoa() step, and would be much faster. I imagine this would about 4-8 lines of XS code and would be drammatically faster than using $hash{0+$self}. Ie I can imagine an API like: