Re: Experimental features: autoderef vs postfix deref

For anyone interested, I've been doing some basic benching. Two of the tests are self-explanitory. The "no_braces" test is the same as "circumfix", except that it has all but the mandatory bracing removed. Over the next couple days, I'll do more elaborate testing that can be repeated easily. In this case, after numerous runs, I can only suspect that the 'no_braces' is slower consistently because perhaps perl has to do extra work to decide how to proceed. This is only a guess though. I don't know nearly enough about the guts to know for sure.

Result:

            Rate no_braces circumfix postderef
no_braces 2.59/s        --       -2%       -7%
circumfix 2.64/s        2%        --       -5%
postderef 2.78/s        7%        5%        --
[download]

Benchmark code:

#!/usr/bin/perl
use warnings;
use strict;

use feature 'postderef';
no warnings 'experimental::postderef';

use Benchmark qw(cmpthese timethese);

my $count = 100000;

cmpthese(1000, {
        'circumfix' => \&circumfix,
        'postderef' => \&postderef,
        'no_braces' => \&no_braces,
});

sub circumfix {
    my ($h, $a, @a);
   
    for (1..$count){
        push @{$h->{$_}}, [$_];
    }
    for my $k (keys %{$h}){
        for (@{$h->{$k}}){
            push @{$a}, $_ for @{$_};
        }
    }
    push @a, $_ for @{$a};
}

sub postderef {
    my ($h, $a, @a);
   
    for (1..$count){
        push $h->{$_}->@*, [$_];
    }
    for my $k (keys $h->%*){
        for ($h->{$k}->@*){
            push $a->@*, $_ for $_->@*;
        }
    }
    push @a, $_ for $a->@*;
}

sub no_braces {
    my ($h, $a, @a);
   
    for (1..$count){
        push @{$h->{$_}}, [$_];
    }
    for my $k (keys %$h){
        for (@{$h->{$k}}){
            push @$a, $_ for @$_;
        }
    }
    push @a, $_ for @$a;
}
[download]

Comment on Re: Experimental features: autoderef vs postfix deref Select or Download Code

Replies are listed 'Best First'.
Re^2: Experimental features: autoderef vs postfix deref by shmem (Chancellor) on Jul 13, 2015 at 20:41 UTC
Did you run the benchmark several times? Such small differences are suspicious. It might be more enlightening to use a perl binary with -DDEBUGGING and dump the parse tree. For well implemented variations of syntactic sugar of the same thing I'd expect the the compiler to produce the same tree. perl -le'print map{pack c,($-++?1:13)+ord}split//,ESEL'	[reply] [d/l]
Re^3: Experimental features: autoderef vs postfix deref by stevieb (Canon) on Jul 13, 2015 at 20:54 UTC
I did run numerous times and the results were pretty consistent. I'll definitely do as you suggested to get a better idea, and will post back here with results.	[reply]
Re^2: Experimental features: autoderef vs postfix deref by BrowserUk (Patriarch) on Jul 13, 2015 at 20:08 UTC
Interesting, but probably not very significant. A more interesting figure, that is probably impossible to measure, is what performance affect has this 'feature' had upon code that doesn't use it? With the rise and rise of 'Social' network sites: 'Computers are making people easier to use everyday' Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error. "Science is about questioning the status quo. Questioning authority". In the absence of evidence, opinion is indistinguishable from prejudice. I'm with torvalds on this Agile (and TDD) debunked I told'em LLVM was the way to go. But did they listen!	[reply]
Re^3: Experimental features: autoderef vs postfix deref by stevieb (Canon) on Jul 13, 2015 at 20:59 UTC
I thought that if you don't request the code, it isn't loaded. Can you explain what you mean? Would it be that even though the feature isn't `use`'d, it's still intertwined enough to have effects?	[reply] [d/l]
Re^4: Experimental features: autoderef vs postfix deref by BrowserUk (Patriarch) on Jul 13, 2015 at 21:37 UTC
Would it be that even though the feature isn't use'd, it's still intertwined enough to have effects? It's that I suggested it would be good to measure. Many perl features exact a cost even for code that doesn't use them. Eg. Threads: I recall reading somewhere that building with threads cost something like 7% for code that made no use of them. Unicode: The presence of the code to deal with unicode, means at the very least a lot of extra boolean checks in code paths for code that doesn't use it. Tie: The ability to tie variables means passing through checks for its presence for almost every variable access. Many other kinds of magic impose similar complexities on code that doesn't use it; just to determine that it isn't used. Individually, none of them are hugely detrimental, but combine them all together and the affects on every opcode that has to go through is-it-unicode, is-it-tied, is-it-lvalue, is-it-shared, is-it-someother-magic, add up. Whether this has any such consequences was the question. shmem may be right that this is purely a syntactic sugar thing; recognised entirely at compile time; that compiles to identical code to the normal deref; and thus has no runtime consequences at all. But your numbers above seem to indicate there may be more to it than that. With the rise and rise of 'Social' network sites: 'Computers are making people easier to use everyday' Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error. "Science is about questioning the status quo. Questioning authority". In the absence of evidence, opinion is indistinguishable from prejudice. I'm with torvalds on this Agile (and TDD) debunked I told'em LLVM was the way to go. But did they listen!	[reply]
Re^5: Experimental features: autoderef vs postfix deref by stevieb (Canon) on Jul 13, 2015 at 21:53 UTC
A reply falls below the community's threshold of quality. You may see it by logging in.
Re^5: Experimental features: autoderef vs postfix deref by stevieb (Canon) on Jul 13, 2015 at 22:12 UTC