On Wed, 9 Aug 2000 10:24:28 -0400, John Porter wrote:

>Bart Lateur wrote:
>> 
>> It's not "simple". It's confusing. 
>
>Not at all!  At least, not to me.  If you find it unsimple and confusing,
>then I guess I'll have to chalk it up to the heterogeneity of the Perl
>community.

>> Very often I do stuff like you
>> describe, and then it turns out that there are cases where I needed the
>> chomp, and I forgot to add a newline. 
>
>Strawman.  There are times I forgot to increment the count of frobnitzes,
>and had to go edit the code.

There's no need for that macho "I can lick this" attitude. Being
consistent, everywhere, is clearly simpler.

I've done some benchmarks, copying a 650k file 200 times (over the same
output file every time). I've modified the same script a little, and
then ran it, so that mutual influence of the scripts was minimal. This
is the basic script:

    use Benchmark;
    my $file = 'win32api.txt';
    # $\ = "\n";   # in some versions: explicit setting of $/ to "\n"
    sub go {
        @ARGV = $file;
        open OUT, ">$ENV{TMP}/copy.txt"
          or die "Can't write to file: $!";
        while(<>) {
            # chomp;  # explicit chomp() in some versions
            print OUT;
        }
        close OUT;
    }
    go(); # possibly load file in file cache

    timethis(200, \&go);

Results:

Plain code: no chomp, $\ clear:

   timethis 200: 20 wallclock secs (20.16 usr +  0.00 sys = 20.16 CPU) @
    9.92/s (n=200) 

Command line option = '-l': implicit chomp, $\ set by system:

   timethis 200: 22 wallclock secs (21.42 usr +  0.00 sys = 21.42 CPU) @
    9.34/s (n=200)

No chomp, $\ set to "\n" (double the newlines in output)

   timethis 200: 22 wallclock secs (21.64 usr +  0.00 sys = 21.64 CPU) @
    9.24/s (n=200)

Explicit chomp, $/ set to "\n":

   timethis 200: 24 wallclock secs (23.73 usr +  0.00 sys = 23.73 CPU) @
    8.43/s (n=200)


As it turns out, no chomp() and $/ not set is fastest, explicit chomp()
and $/ set to newline is slowest, difference about 20%. However, it's
the other results that are interesting.

It turns out that $/ set to "\n" (by system) and implicit chomp is AS
FAST as $/ set to "\n" and no chomp at all. (The results are halfway
between both extremes. The output files are slightly different, so take
times with a grain of salt.) An explicit chomp does slow down my program
by a large amount of about 10%. Seen the small task it does, compared to
reading and writing the files, that is a lot.

If there is any optimization to be done, it is in the appending of the
"\n" at the end when printing (again, 10% of total time). This is quite
slow, it must be possible to do this a lot faster. But I think that in
principle, this shows that an implicit chomp does NOT slow down the
program. By contrast, an explicit chomp() does, and quite a bit.

Oh, and doing

        print "$_\n"; 

or

        print $_, "\n";

turns out to be quite a bit slower still than using the feature of $\.
(time above 27 seconds)

-- 
        Bart.

Reply via email to