You could also force stringification to get an even bigger speedup compared to calling pack on every hash access (if that's what you're doing), e.g. $x = "$x" or $_="$_" for @values;. Update: Added the pre-packed test with $p, which surprisingly is still not as fast as the stringified float $y. Update 2: By giving each test case its own hash instead of using one hash for all tests, now the test cases "y" and "p" perform roughly the same, as I would have originally expected (Update 3: However, across multiple runs of this benchmark, "y" still tends to outperform "p", often significantly). Update 4: If you set $x = 42.123456789, then "p" consistently outperforms "y", so I'd guess it has to do with the hash key length. (last update, I promise ;-) )
use Benchmark qw/ cmpthese /; my $x = 42.0; my $y = "$x"; my $p = pack 'F', $x; my (%h1,%h2,%h3,%h4); cmpthese( -1, { F => sub { $h1{ pack 'F', $x } = 1 }, s => sub { $h2{ $x } = 1 }, y => sub { $h3{ $y } = 1 }, p => sub { $h4{ $p } = 1 }, }); __END__ Rate s F p y s 4032984/s -- -64% -84% -84% F 11327209/s 181% -- -54% -56% p 24707825/s 513% 118% -- -5% y 25997751/s 545% 130% 5% --
In reply to Re: Any reason NV is not marked as POK when accessed as string? (updated)
by haukex
in thread Any reason NV is not marked as POK when accessed as string?
by vr
| For: | Use: | ||
| & | & | ||
| < | < | ||
| > | > | ||
| [ | [ | ||
| ] | ] |