It makes sense when your Benchmark tests say it's a problem but not prior. Consider that you're also making a copy of the data which might have it's own implications (unless you get Copy-On-Write (unless that's only a perl6ism)). I'd almost consider this sort of thing right along with the my ($a); vs my $a; optimization. I'd do it for notational convenience but not much else (unless you really do have thousands of entries in your hash and you really, really, really, really care about the pico seconds you're losing ...).
Update: There is a difference between my ($foo) and my $foo - one has to include an extra OPCODE or two to coerce the scalar into list context while the other is already there. I'll leave it to you and B::Terse to figure out which one is "cheaper".
__SIG__ printf "You are here %08x\n", unpack "L!", unpack "P4", pack "L!", B::svref_2object(sub{})->OUTSIDE;
In reply to Re: Should we bother to save hash lookups for performance?
by diotalevi
in thread Should we bother to save hash lookups for performance?
by dlink
| For: | Use: | ||
| & | & | ||
| < | < | ||
| > | > | ||
| [ | [ | ||
| ] | ] |