The reason I suggested it is in case someone wanted to use your SuperSplit with tied filehandles. I would not depend on a tied filehandle correctly paying attention to $/, so the join makes sense.

But if you care about performance or have good reason to believe that people won't use tied filehandles, then avoid join.

For the best of both worlds, use both:

my $contents= do { local($/); join '', <INPUT> };
[download]

should work quickly for file handles that pay attention to $/ and work about as quickly as possible for those that don't.
        - tye (but my friends call me "Tye")

Modified davorg's code accordingly. Some improvement, clearly:

Benchmark: timing 50000 iterations of hybrid, join, slash...
    hybrid:  4 secs ( 2.90 usr  0.38 sys =  3.28 cpu)
      join:  6 secs ( 5.65 usr  0.35 sys =  6.00 cpu)
     slash:  3 secs ( 1.95 usr  0.38 sys =  2.33 cpu)
[download]

Cheers,

Jeroen
I was dreaming of guitarnotes that would irritate an executive kind of guy (FZ)

-- Randal L. Schwartz, Perl hacker

Yes they were :) But I'm not sure I like the results. Is there a problem with this benchmarking code?

#!/usr/bin/perl -w
use strict;

use Benchmark;

my $file = $0;
open IN, $file or die "$file: $!\n";

sub joinit { my $content = join '', <IN>; }

sub dollarslash { my $content = do { local $/; <IN> } }

timethese(100_000, {join => \&joinit,
                    slash => \&dollarslash} );
[download]

because it implies that the join is faster...

Benchmark: timing 100000 iterations of join, slash...
      join:  2 wallclock secs ( 1.52 usr +  0.29 sys =  1.81 CPU)
     slash:  4 wallclock secs ( 2.99 usr +  0.35 sys =  3.34 CPU)
[download]

--
<http://www.dave.org.uk>

"Perl makes the fun jobs fun
and the boring jobs bearable" - me

Yes, you forgot to seek so most of the iterations don't read anything so you are only measuring overhead. (:

        - tye (but my friends call me "Tye")