in reply to Re^3: Best way to store/sum multiple-field records?
in thread Best way to store/sum multiple-field records?

Not only 'premature optimization is the root of all evil'; not only such a microoptimization is completely meaningless; but it's actually the other way around... declaring variables inside a loop is quite a bit faster.

Really? Go figure> (It's (much) more complicated than that!):

use strict;
use warnings;

use Benchmark qw( cmpthese );

my @strings = qw(
  USERID1|2215|Jones|
  USERID1|1000|Jones|
  USERID3|1495|Dole|
  USERID2|2500|Francis|
  USERID2|1500|Francis|
);

cmpthese(
    -1,
    {
        outside => sub {
            my ( $x, $y, $z );
            for (@strings) {
                ( $x, $y, $z ) = split /\|/;
            }
        },
        outside2 => sub {
            my ( $x, $y, $z );
            for (@strings) {
                ( $x, $y, $z ) = split /\|/, 3;
            }
        },
        inside => sub {
            for (@strings) {
                my ( $x, $y, $z ) = split /\|/;
            }
        },
        inside2 => sub {
            for (@strings) {
                my ( $x, $y, $z ) = split /\|/, 3;
            }
        },
    }
);

__END__
C:\test>junk
             Rate  outside   inside  inside2 outside2
outside   58201/s       --     -38%     -71%     -73%
inside    93659/s      61%       --     -53%     -57%
inside2  197610/s     240%     111%       --     -10%
outside2 218802/s     276%     134%      11%       --

[download]

When you can explain that; then you may pontificate on the subject.

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.

Replies are listed 'Best First'.
Re^5: Best way to store/sum multiple-field records? (carte blanche)
by tye (Sage) on Dec 23, 2014 at 05:39 UTC
    When you can explain that; then you may pontificate on the subject.

    Explanation: You wrote broken code. 

    $_ = 'USERID1|2215|Jones|';
my( $x, $y, $z ) = split /\|/;
print "( $x, $y, $z )\n";
( $x, $y, $z ) = split /\|/, 3;
print "( $x, $y, $z )\n";
__END__
( USERID1, 2215, Jones )
( 3, ,  )

    [download]

    Thanks for the permission. (:

    Update: Oh, and the explanation for the other part of the "(much) more complicated" mystery: 

                 Rate  outside   inside  inside2 outside2
outside   58201/s       --     -38%     -71%     -73%
inside    93659/s      61%       --     -53%     -57%
inside2  197610/s     240%     111%       --     -10%
outside2 218802/s     276%     134%      11%       --

    [download]

    That is, why is "outside" faster than "inside" while "inside2" is faster than "outside2"? Well, that's the classic point I try to get people to remember all the time: "11%" is simply "noise". Whether "inside2" or "outside2" will "win" depends on mostly random stuff (which one gets run first being the least random contributor that I've noticed).

    - tye        

[reply]
[d/l]
[select]
      I thought it would be interesting to run BrowserUk's benchmark after having fixed the two little defects.

      This is the modified code:

      Read more... (1023 Bytes)
      And the benchmark results: 
      $ perl bench_inside_outside.pl
             Rate  outside outside2   inside  inside2
outside   90269/s       --     -20%     -40%     -51%
outside2 113390/s      26%       --     -25%     -39%
inside   151060/s      67%      33%       --     -19%
inside2  185735/s     106%      64%      23%       --

      [download]
      So, (hoping the code is now correct), the results are now consistently showing (1) the quite strong advantage of declaring the variables inside the loop compared to doing before entering the loop (these results are well in line with AnonMonk's reported results), and (2) that choroba's idea to specify a limit also bring a measurable improvement (much less strong than the inside/outside declaration, but I would tend to think that a difference of about 25% is significant, and no longer noise).

      That second point is interesting, because I have experienced in the past that specifying a limit brings an improvement when the string being split would yield (without limit) more fields than the limit, presumably because Perl is able to stop processing the string as soon as the limit is reached, but I would have thought that this advantage would to a large extent vanish when the limit is the same as the number of potential fields in the string being split. Good to know. Thank you choroba for this comment.

[reply]
[d/l]
[select]

        Well, if you had repeated the same check that I did above (verify that your different approaches are actually doing the same thing), then you would have found that specifying the limit does indeed change the results (making the benchmark of questionable validity).

        Also, split documents that the code without the limit actually infers a limit. That is, these two lines are equivalent: 

        ( $x, $y, $z ) = split /\|/;
( $x, $y, $z ) = split /\|/, $_, 4;

        [download]

        But the (implied) limit is 4, not 3, because that limit actually results in not changing the results you get. This also results in no performance improvement.

        I would tend to think that a difference of about 25% is significant, and no longer noise

        Well, the 25% rises slightly above the level of simply "noise", in that it is likely just enough to be at least moderately consistent (not flipping to a negative value on subsequent runs of the same benchmark). For such micro operations, even 20% can easily be simply noise, IME.

        I actually think that Benchmark.pm should not (by default) try to "subtract overhead" as this (understandable) attempt to increase accuracy almost always just produces misleading or useless information. If the operations being benchmarked are so small that subtracting overhead matters much, then they are also so small that (in Perl) the moderate changes in their performance almost never matter.

        So I certainly disagree that getting Perl to skip stripping just the final "|" is "significant" when considering performance (but certainly could be significant as to whether your results are correct or not). Build a real script that does something useful with the benchmarked code and then add in the limit of 3 (and tolerate getting different results) and I'd be shocked if the performance difference is something anybody would notice. The total performance change might even be so small as to make it difficult to even consistently measure. (Of course, if you drastically change, for example, the data being operated on, then you can drastically change the performance differences and so the results could be completely different -- even in the opposite direction.)

        And I consider "is significant" to be a higher bar than "is noticeable" (which is higher than "can be measured").

        If you want to know if you have actually found a performance improvement that is "significant", then you really need to benchmark operations that (in Perl) take a lot more than 1 micro-second.

        You can do this by operating on more or larger data. Though, this makes your benchmark of questionable validity if you won't be dealing with such data in reality. Or you can iterate many times within each bit of code being benchmarked. This also may threaten the validity of your benchmark if the code in question will never be iterated in such a direct way, of course.

        If you want accurate benchmarks, then benchmark code that is an accurate representation of what your real code will be doing. Your real code doesn't get to "subtract overhead" so Benchmark.pm doing that mostly makes the results less realistic (but more "fun").

        - tye        

[reply]
[d/l]
      Explanation: You wrote broken code.

      Thanks. That had me stumped.

      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.
[reply]
Re^5: Best way to store/sum multiple-field records?
by GotToBTru (Prior) on Dec 23, 2014 at 21:42 UTC

    I feel better about this now ;)

    1 Peter 4:10
[reply]
      I feel better about this now ;)

      S'not the first time I've been caught out by a benchmark, and trust me, it won't be the last :)

      And we are in good company!

      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.
[reply]

In Section Seekers of Perl Wisdom