in reply to Re (tilly) 3: References
in thread References

I did some benchmarking 
#/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]
Which gives me: 
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]
I was expecting there to be at least some difference, since b has to dereference it every time.

Replies are listed 'Best First'.
Re (tilly) 5: References
by tilly (Archbishop) on Aug 20, 2001 at 15:58 UTC
    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.

[reply]
Listen to Tilly ... he knows what's what!
by dragonchild (Archbishop) on Aug 20, 2001 at 16:35 UTC
    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!

[reply]
[d/l]
[select]
      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
[reply]
        Now, you've piqued my curiousity. Why on earth would you want to filter out the most powerful syntax tool in Perl since the subroutine?!? References are the sole thing that took Perl from a glorified scripting language to a programming language that rivals the expressibility of almost every other C-like language out there!

        In addition, references are not a very complicated concept. Try explaining how C does strings to something, one day. Or, try explaining the friends concept in C++. All of a sudden, references become reeaaaalllly simple.

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

        Vote paco for President!

[reply]

In Section Seekers of Perl Wisdom