#/usr/bin/perl -w

use strict;
use Benchmark;

sub f {
  our %d;
  local *d = shift;
  $d{$_}=$_ foreach (0 .. 200);

}

sub b {
  my $d = shift;
  $$d{$_}=$_ foreach (0 .. 200);
}

my %c;

timethese (100000, {
   'f' => '&f(\%c)',
   'b' => '&b(\%c)',
});
[download]

Benchmark: timing 100000 iterations of b, f...
         b: 83 wallclock secs (67.82 usr + 14.38 sys = 82.20 CPU) @ 12
+16.55/s (n=100000)
         f: 80 wallclock secs (65.86 usr + 13.95 sys = 79.81 CPU) @ 12
+52.98/s (n=100000)
[download]

My guess is that any dereferencing overhead is invisible next to the overhead of constructing scalars and then stringifying them.

As for the performance issue, the general programming principle is that premature optimization is the root of all evil. Furthermore if performance really is critical, then Perl is the wrong language to use. Perl will speed development, has very large reusable libraries, improves reliability by doing memory management for you, etc, etc, etc. But while it is fast for a scripting language, far faster ones exist out there.

Cine - you're missing the point tilly's trying to make. The two syntaxes you're using, while legal, are horrid programming practice. Absolutely horrid.

The first breaks all sorts of scoping suggestions by using a lexical global within a tiny function, then using a scoped global right after! Do not do this!! Whenever I see this kind of crap in some program I've been asked to maintain, I rip it out immediately. Of course, it usually takes me an hour or so to do this, just because I can never be sure that there aren't dependencies elsewhere.

The second is a back-asswards way of dereferencing a hashref that would confuse the heck out of me, and anyone else who would read your code. I can read it now, but only because I have some context within which to read it. Again, if I ever saw this in some code I was maintaining, I would rip it out in a heartbeat!

"What should I do?" you ask? Do the following:

sub c {
    my $d = shift;
    $d->{$_} = $_ foreach (0 .. 200);
}
[download]

And get used to it! This is the way people will write code for you to maintain. You will read this syntax.

In addition, if you're freaking out about which is faster, I decided to run your Benchmark script, adding in my subroutine. Just for kicks. Here're the results I got:

b: 154 wallclock secs (153.27 usr + 0.00 sys = 153.27 CPU) @ 1216.55/s
+ (n=100000)
c: 152 wallclock secs (153.17 usr + 0.00 sys = 153.17 CPU) @ 1216.55/s
+ (n=100000)
f: 156 wallclock secs (156.57 usr + 0.00 sys = 156.57 CPU) @ 1252.98/s
+ (n=100000)
[download]

Pretty interesting, huh?

------
/me wants to be the brightest bulb in the chandelier!

Vote paco for President!

I'm sorry I'm not making myself clear in what my goal is.
First off I wanted to know if there were an easy and understandble way to filter out references, so that it was transparent that it was the hash from the caller that was being worked on. This was to archieve a way to hide the "gory" details about references ;)

When I figured out that the only way to do this is to alter the symbol table (which is a hell of a lot more difficult to read and understand), I was curious if there were a visible speed difference, which I gladly saw there was not.
Alas now I NO reason use this now.

ps. As Efficiency of $$var, ${$var} shows there is no difference in b and c.

T I M T O W T D I