Re: Unexplained benchmark when using chop vs. chomp (or neither)

[davido]

The following code strives to test only chop, chomp, and a noop for the same number of iterations, with the same starting data on each iteration. As far as is practical it attempts to maintain simplicity and to establish a control group (mynada) that performs as similar an algorithm as possible to the two other alternatives. Observe this code and the results:

 use strict;                          
 use warnings;                        
                                      
 use Benchmark qw(cmpthese);          
                                      
                                      
 my @orig = ("\n") x 100000;          
                                      
                                      
 sub mychomp {                        
     my $data = shift;                
     my @copy = @$data;               
     chomp for @copy;                 
 }                                    
                                      
 sub mychop {                         
     my $data = shift;                
     my @copy = @$data;               
     chop for @copy;                  
 }                                    
                                      
 sub mynada {                         
     my $data = shift;                
     my @copy = @$data;               
     1 for @copy;                     
 }                                    
                                      
                                      
 cmpthese -10, {                      
     chomp   => sub {mychomp(\@orig)},
     chop    => sub {mychop(\@orig)}, 
     nada    => sub {mynada(\@orig)}, 
 };

This produces (on my system):

        Rate chomp  chop  nada
chomp 87.8/s    --   -4%  -20%
chop  91.6/s    4%    --  -16%
nada   109/s   25%   20%    --

This shows me that the noop is about 20%-25% faster than the other two alternatives, and that the other two are only 4% apart, which is really within the margin for error.

The fact that you are getting more dramatically different results might indicate that the experiment is not as pristine as it should be, and that you are comparing non-equivalent alternatives.

[choroba]

Note that both chop and chomp can take an array as the argument. Interestingly,

chop @copy;

makes mychomp and mychop just as fast as nada.

[davido]

Yes, I had considered setting up alternatives that pass an array to chomp and chop, but figured it wasn't going to be a very useful comparison for this specific situation. But absolutely, pushing the loop into internals is going to be a lot faster. In fact it wouldn't have surprised me if you had said that the array version was even faster than the 'nada' version, since the 'nada' version still has a loop, unless it's been optimized away, which I'm not sure on.

[ikegami]

A better way of reading your results:

Each chomp took 1/(87.8/s)/100000 = 114 ns (including overhead)
Each chop took 1/(91.6/s)/100000 = 109 ns (including overhead)
Each nada took 1/(109/s)/100000 = 92 ns

so

Each chomp took 22 ns
Each chop took 17 ns

It's not surprising that chop is faster than chomp (since what it does is far, far simpler), but they are both seriously fast! What this means is that trying to optimize this is a waste of time; there is far more "fat" to trim elsewhere.