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 ( #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
Node Status?
node history
Node Type: note [id://492699]
help
Chatterbox?
[Corion]: Yaerox: That's a somewhat hard problem. Encode solves the conversion part, but for guessing what encoding a file is in, that's the hard part
[Corion]: Yaerox: There is Encode::Guess, but that needs a limited set of inputs, and it also cannot handle multiple single-byte encodings
[Corion]: If you have a BOM, that's a really easy way to recognize UTF-8. Otherwise, you can try to decode a file from UTF-8, and if that works OK and doesn't crash, most likely the file was valid UTF-8
[Corion]: But as "ansi" (Latin-1?) is a single-byte encoding, any file is a valid ANSI file

How do I use this? | Other CB clients
Other Users?
Others having an uproarious good time at the Monastery: (6)
As of 2017-03-28 13:19 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?
    Should Pluto Get Its Planethood Back?



    Results (332 votes). Check out past polls.