Beefy Boxes and Bandwidth Generously Provided by pair Networks
Clear questions and runnable code
get the best and fastest answer
 
PerlMonks  

Re^4: Threads and fork and CLONE, oh my!

by jdhedden (Deacon)
on Sep 16, 2005 at 17:57 UTC ( [id://492699]=note: print w/replies, xml ) Need Help??


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

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.


Remember: There's always one more bug.
  • Comment on Re^4: Threads and fork and CLONE, oh my!

Replies are listed 'Best First'.
Re^5: Threads and fork and CLONE, oh my!
by xdg (Monsignor) on Sep 16, 2005 at 18:26 UTC

    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.

      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

Re^5: Threads and fork and CLONE, oh my!
by adrianh (Chancellor) on Sep 18, 2005 at 08:28 UTC
    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!

    You're right, but this isn't the reason that using $self is so much slower. Stringification of references is just slow:

    #! /usr/bin/perl use strict; use warnings; use Benchmark qw( cmpthese ); my $self = bless {}, 'SomeClass'; my $string = "$self"; my %a = ( $self => 0 ); my %b = ( $string => 0 ); cmpthese(-1, { self => sub { $a{ $self } = $a{ $self } + 1 }, string => sub { $b{ $string } = $b{ $string } + 1 }, }); __END__ # on my perl 5.8.7 Rate self string self 156393/s -- -83% string 927942/s 493% --
    On another minor note, 0+$self yields the same result as the refaddr function.

    Unless you overload arithmetic.

Re^5: Threads and fork and CLONE, oh my!
by demerphq (Chancellor) on Nov 15, 2005 at 14:41 UTC

    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.

    Only when nummification is NOT overloaded. And in earlier perls you can't unoverload nummification.

    ---
    $world=~s/war/peace/g

Log In?
Username:
Password:

What's my password?
Create A New User
Domain Nodelet?
Node Status?
node history
Node Type: note [id://492699]
help
Chatterbox?
and the web crawler heard nothing...

How do I use this?Last hourOther CB clients
Other Users?
Others sharing their wisdom with the Monastery: (5)
As of 2024-04-23 21:00 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    No recent polls found