RE: Re: always in quest to eliminate temporary variables

[visnu]

sweet.. but i wonder how efficient that is?

[plaid]

It shouldn't really affect the efficiency much, as you're limitting the split to a maximum of two results returned, and so having a longer string passed to the split won't affect it. Either way, the difference in efficiency will be negligible

use Benchmark;
use strict;

timethese(1000000, { 'One Liner' => \&one_liner, 'Two Liner' => \&two_
+liner });

sub one_liner {

        # Stick all variables in the functions, so we can
        # see if there's any extra overhead for the extra
        # variable in two_liner.

        my $text = q/Here is some test text.
                   I don't really know what I'm typing here, but
                   does it really matter?  I don't think so.  I'm just
                   kind of hitting random keys and stuff/;
        my $next_line;

        ($text, $next_line) = split /\n/, $text.$next_line, 2;
}

sub two_liner {
        my $text = q/Here is some test text.
                   I don't really know what I'm typing here, but
                   does it really matter?  I don't think so.  I'm just
                   kind of hitting random keys and stuff/;
        my($next_line, $pre_next_line);

        ($text, $pre_next_line) = split /\n/, $text, 2;
        $next_line = $pre_next_line . $next_line;
}

Benchmark: timing 1000000 iterations of One Liner, Two Liner...
 One Liner: 21 wallclock secs (19.85 usr +  0.00 sys = 19.85 CPU)
 Two Liner: 22 wallclock secs (22.85 usr +  0.00 sys = 22.85 CPU)

[visnu]

the difference between the two isn't the split as much as the string concatenations and corresponding memory allocations. the split will split in the same place and do pretty much the exact same thing in both cases (assuming of course that it works its way from the front and not the back as mentioned above).

all in all, i'd suggest that they're pretty much the same...

[Adam]

I don't know how efficient (or not efficient) split is. I assume that since split finds the first match in the string (rather then the last) that it isn't using greedy pattern matching. If this is the case, then the matches start at the begining and iterate to the end (whereas greedy goes the other direction) and this means that stuff tacked onto the end of the string won't alter the "efficiency" of the match except in the case where no match is found. I think. I trust that some of the more experienced (and knowledgable) gurus amongst us will correct me if I'm wrong. If I'm right, then there is no efficiency loss with my method.

By the way, there is no garuntee that your not using a temporary variable will keep one from being created. Compilers are funny things that way.