

Benchmarking Perl subroutine signatures - nkurz
http://perltricks.com/article/88/2014/5/12/Benchmarking-subroutine-signatures

======
onedognight

        sub native_assignment { 
            die "Too few arguments for subroutine $!" unless @_ == 1; 
            my $var = @_;
        }
    

There is a bug here. This assigns $var to the number of arguments so it's not
the same the versions below that are being compared to.

    
    
        sub native_signature ($var) {}
    
        func method_signature ($var) {}

------
DrinkWater
it's a shame there aren't more perl posts on hn. would love to see that.

------
acqq
I don't understand the tables (how can the second table show improvement when
the "minus" is -37 vs -25 the first time and the text explains that -25 is the
slowdown, why making the 2 D table when the another dimension doesn't
introduce new measurements). I'd prefer one dimension and not two, and the
data of one dimension normalized to one speed being 1. Ignoring the tables, I
interpret the graph to show that signatures are almost 30% slower than the old
method? Old method almost 4M per sec, signatures 3M per sec. So signatures are
cleaner to write, but it would be much more inviting if there wouldn't be a
penalty paid. I understand that they wanted to add extra checking, but I'd
prefer that the extra checking is only compile-time by default.

IMO the default of features should be a net win. Otherwise everybody's
favorite performance tip is going to be "don't use that feature."

My approach would be: the signatures by default are just an alternative syntax
to

    
    
        sub f {
           my ( $a, $b, $c ) = @_;
    

and the new checks are only compile-time, and the new run-time checks are
activated by switch or "use." Then nobody would have any reason to keep
writing old style except when needed to run on older versions.

~~~
simcop2387
The tables are the standard format from the benchmarking module used. I agree
they are annoying to grasp at first, a better format should be found.

But what's going on is that in the second one it's showing that Method-
Signature is taking 23% longer than native signature, and 37% longer than
native assignment. The second row shows native-signature taking 30% less time
(this is the other direction from method-signature vs native-signature, so the
values are inverses of eachother), and being 18% slower than native
assignment.

I'm not sure why it it's significantly different performance wise, but i'd
expect that to be fixable in the future. Part of it is the explicit check it
adds normally for the number of parameters.

It's possible that it's implemented by doing shifts so it performs more like

    
    
        sub f {
          my $a = shift;
          my $b = shift;
          my $c = shift;
    

That would help the slurpy parameter to be easy to implement internally but
would mean that there's possibly some extra copies that don't need to happen
because it creates a new @_ each time when it pulls the first value off.

------
slashdotaccount
Kavorka is the best signatures module. It has the most features and the
fastest speed.

[http://p3rl.org/Kavorka](http://p3rl.org/Kavorka)
[http://buzzword.org.uk/2013/featuritis.html](http://buzzword.org.uk/2013/featuritis.html)

