#!/usr/bin/perl
use strict;
use warnings;
use Benchmark::Forking qw( timethese cmpthese ); # UnixOS
# use Benchmark qw(:all) ; # WindowsOS

my @preserved = @ARGV;

sub test_grep {
    @ARGV = @preserved; # restore original @ARGV
    my @matched = grep { $_ =~ /AGGT/ } <>;

    if (@matched) {
    for(@matched) { chomp $_;
            print "Grep: " . length($_) . "\n";}
    }
    close ARGV if eof;
}

sub test_while {
    @ARGV = @preserved; # restore original @ARGV
    my $count;
    while (<>) {
    if ($_ =~ /^>hsa/){
        chomp (my $line = <>);
        $count .= length($line);
        $count .= " ";
    }
    } continue {
    close ARGV if eof; # reset $. each file
    }
    print "While: " . $count . "\n";
}

my $results = timethese(2, { Grep => \&test_grep, While => \&test_whil
+e }, 'none');
cmpthese( $results );
[download]

Hello tobyink,

Thanks, worked perfectly. :D

But share some light, why is it working with @ARGV = @preserved; # restore original @ARGV?

Thanks again for your time and effort.

Seeking for Perl wisdom...on the process of learning...not there...yet!

You need to understand what the diamond operator does:

• Does the operator have an active filehandle, if not, shift an argument off @ARGV and open it for input as the active filehandle or if @ARGV is empty, set the active filehandle to STDIN.
• If called in list context, return all lines from the active filehandle.
• If called in scalar context and the filehandle is at the end of the file, return undef.
• Otherwise, return a single line from the filehandle.

That's pretty much it. I might be forgetting some subtleties.

The key bit, I've highlighted for you in bold. It uses @ARGV to figure out what file to read, and it alters that array!

So the first time you read a file using the diamond operator, you read it fine. The second time you try to read the file, the filename is no longer on @ARGV, so the diamond operator reads from STDIN instead.

> But share some light, why is it working with @ARGV = @preserved; # restore original @ARGV?

I' dunno well your skills but if you have not understood what the venerable monk tobyink says below, and directly answering to your cited above assertion:

the <> diamond operators consumes @ARGV so if you save a safe copy in @preserved you can refill @ARGV when you need ie first line of the two subs in the tobyink's example above.

As said below the <> diamond can also feed @ARGV opening SDTIN as last resource, so the above works because it restores @ARGV original contents at the top of the two testing subs.

L*

There are no rules, there are no thumbs..
Reinvent the wheel, then learn The Wheel; may be one day you reinvent one of THE WHEELS.

The <> diamond operator, acting upon @ARGV is going to be tricky to get right, if you want to re-read the same file multiple times to benchmark. Better off using open to manually act upon the filenames passed into @ARGV. That way you can re-open for each run, or (probably faster), open once, tell, and seek to reset between iterations.

There are faster alternatives than <>, but if your drive is a mechanical drive, shifting over to SSD is the biggest win.

Hello davido,

Alternatives than <> that are faster? Can you propose some so I could use them as future reference?

Thank you for your time and effort.

Seeking for Perl wisdom...on the process of learning...not there...yet!

<> is a general purpose tool, and as such is optimized for "the general case." There isn't one single tool that can optimize for speed across the general case (or in other words, the majority of all use cases). If you know your data-set well, you can optimize by selecting a less general tool to fit your specific need. Tools to consider include:

• read: May be faster for small reads.
• sysread: May be faster for large reads.
• Sys::Mmap and File::Map: May be faster for large files in some specific cases.
• Lower-impact layers (eg :raw or :mmap) may offer speed advantages in some cases while reducing functionality in other areas.

Each of these methods come with caveats, pitfalls, limitations, and unique benefits. It is up to you to decide if the limitations are outweighed by the benefits for your specific use case. benchmarking is the only way you'll be sure that one is a win over the other for your specific situation.




Dave

Hi, if I understand you correctly, the issue is that the diamond operator uses shift to iterate through @ARGV, so the second sub will find it empty.

$ perl -Mstrict -Mwarnings -E 'say "starting: " . scalar @ARGV; while(
+<>){chomp; say "$_\nremaining: " . scalar @ARGV}' foo bar baz
[download]

starting: 3
foo
remaining: 2
bar
remaining: 1
baz
remaining: 0
[download]

Hope this helps!

Update: added demo

Hello 1nickt ,

I assume the same, but how can I make my script to stop after parsing the first input? I want to avoid using @ARGV but this would be my last option.

Any ideas? Thanks for your time and effort.

Seeking for Perl wisdom...on the process of learning...not there...yet!

close ARGV if eof;

I haven't tested any of this, but I believe this close statement in each of the test_* functions will prevent the other from doing anything: you can't read anything on a closed filehandle. Rather than close-ing the ARGV filehandle, I would seek to the beginning of the handle before each data-read operation in each test function.

Update:

... seek to the beginning of the handle before each data-read operation in each test function.

Hello AnomalousMonk,

Well I thought that closing the file would allow to open the file again on next iteration. I could try to apply what you proposed and see how it goes.

Thanks for your time and effort.

Seeking for Perl wisdom...on the process of learning...not there...yet!