[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