That's interesting. As is often the case with Perl, things move (silently) on as new versions appear. I just re-ran a series of tests that I last performed shortly after IO layers were added.
Back then, on my system ':raw' was exactly equivalent to using binmode. It no longer is, nor is either the fastest option.
Using this:
#! perl -sl
use Time::HiRes qw[ time ];
our $LAYER //= ':raw';
our $B;
$s = time;
open (FILE, "<$LAYER", "junk.bin")
or die "ERROR: Could not open $path.\n";
binmode FILE if $B;
$n=0;
while (1) {
$eof = read (FILE, $header, 4);
($size, $code, $ftype) = unpack ("nCC", $header) ;
# print join(':',$size, $code, $ftype, "\n");
if ($size == 0) {
print "Size is zero. Exiting";
last;
}
$size = $size - 4;
if ($size > 0) {
$eof = read (FILE, $data, $size);
}
$n += 4 + $size;
}
close FILE;
print $n;
printf "Took %.3f\n", time() - $s;
You can see (and interpret) the results for yourself:
On my system, I'll be using :perlio & binmode for fast binary access from now on. (Until it changes again:)
Perhaps even more indicative of the lag in the documentation is this: C:\test>junk41 -LAYER=:crlf
Size is zero. Exiting
50466132
Took 0.668
C:\test>junk41 -LAYER=:crlf -B
Size is zero. Exiting
50466132
Took 0.283
C:\test>junk41 -LAYER=:crlf:raw
Size is zero. Exiting
50466132
Took 0.815
C:\test>junk41 -LAYER=:crlf:raw -B
Size is zero. Exiting
50466132
Took 0.845
If :raw popped all layers that were incompatible with binary reading, then :crlf:raw should be as fast as :crlf + binmode. But it ain't!
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.
|