http://qs321.pair.com?node_id=492715


in reply to Re^4: Threads and fork and CLONE, oh my!
in thread Threads and fork and CLONE, oh my!

Cool. Hadn't realized that was the case about hash keys.

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.

Replies are listed 'Best First'.
Re^6: Threads and fork and CLONE, oh my!
by demerphq (Chancellor) on Nov 15, 2005 at 14:49 UTC

    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:

    ref_key_store(%hash,$ref,$value); my $val=ref_key_fetch(%hash,$ref);
    ---
    $world=~s/war/peace/g