[tpm] Is there a three-way version of...

Shaun Fryer sfryer at sourcery.ca
Sat May 30 21:30:48 PDT 2009


Well, after taking another look at the "sub { shift()->{foo} = shift
if @_ }", I realize my head is full of sand today. *sigh* Trying to be
too clever without being careful enough... Anyway... thanks again Uri,
etc. Good food for thought. Btw, you're totally right about shift
versus copy.

bash> perl

    sub foo {
        my $this        = shift;
        my $that        = shift;
        my $the_other   = shift;
        my $this_other  = shift;
        my $that_other  = shift;
    }

    sub bar {
        my ($this, $that, $the_other, $this_other, $that_other)  = @_;
    }

    my $iterations = 10000000; # ten million

    my $start_foo = time;
    foo() for 0 .. $iterations;
    my $end_foo = time;
    my $foo_time = $end_foo - $start_foo;

    my $start_bar = time;
    bar() for 0 .. $iterations;
    my $end_bar = time;
    my $bar_time = $end_bar - $start_bar;

    print "foo() took $foo_time seconds\n";
    print "bar() took $bar_time seconds\n";

    my @times = sort { $a <=> $b } $foo_time, $bar_time;

    print ( $foo_time == $times[0] ? 'foo()' : 'bar()' );
    print ' was faster by ' . ( $times[1] - $times[0] ) . " seconds.\n";
^D
foo() took 26 seconds
bar() took 20 seconds
bar() was faster by 6 seconds.

Cheers,
Shaun Fryer

> actually shift isn't faster. shift has to copy the data and also modify
> a pointer in @_. assigning @_ to a list only needs to do the copy. and
> multiple assignments with shift is slower than a single list assignment
> from @_. a general rule of thumb (though easily broken) is that the less
> perl code the faster. this is because most perl ops take about the same
> amount of time and the op loop itself is the main overhead.


More information about the toronto-pm mailing list