in reply to PerlIO slower than traditional IO?

First of all your test cases must be simple and focused, so that you compare those two IO methods directly, and don't add anything on top. Otherwise your test cases are not fair.

I have tested the following two cases on windows xp:

use strict;
use warnings;

my $t0 = time();
for (1..10) {
    open(F, "<:utf8", "noname2.txt");
    while (<F>) {
        ;
    }
    close(F);
}
print time() - $t0;

[download]

And

use strict;
use warnings;

my $t0 = time();
for (1..10) {
    open(F, "<", "noname2.txt");
    while (<F>) {
        ;
    }
    close(F);
}
print time() - $t0;

[download]

Both read a 34M utf file. The traditional one took 8-9 seconds, and the utf8 layer one took 11 seconds. So the one with the utf8 layer is slower as expected.

Secondly, should you expect the layered PerlIO be faster? No. And other monks have already provided good reasons above.

Go beyond Perl, I will take Java IO as an example - some sort of opposite example. Java was famous for its "layers" - layered design everywhere. The latest Java versions started to support a rawer IO method, and the IO speed is significantly improved. Was that expected? Yes that was expected.

Replies are listed 'Best First'.
Re^2: PerlIO slower than traditional IO?
by saintmike (Vicar) on Aug 15, 2005 at 01:30 UTC
    Thanks for clarifying that -- guess I was just looking for a good reason to use PerlIO. And performance was the most obvious one.

    So, assuming that the layered design is slower (and also more complex to implement as it seems), what would be a good reason to choose perlIO over the traditional approach? Admittedly, being able to write 

        open(my $in,"<:via(MD5)", $file)

    [download]
    is pretty cool, but I'm not sure I would trade performance or ease of implementation for it.

    Are you saying that modules like PerlIO::via::MD5 or PerlIO::gzip are just academical excercises?

[reply]
[d/l]

      I see two layers ;-)

      First layer, PerlIO itself. It was mainly designed to make Perl IO more portble. Which is a fine idea, as to be portable was one of Perl's key selling point. However nowadays, lots of languages are portable. So it is questionable whether this is still a string selling point. But being not portable is definitely no good for a language like Perl. So the game rule is like this now: being portable is not unique any more, but being not portable is not a choice.

      Second layer, those layers done for specific purposes. For example PerlIO::gzip etc. If you need it, fine, go use it. But what if they don't exist, who cares.

      Any way, performance was not a design goal for PerlIO.

      Hmm... layers of abstraction.

[reply]
        This hits on something that a good CS education should teach - abstraction is often very cool and provides some interesting ways to write code, but it often comes at the cost of performance.

        The trade-off between performance and abstraction is something to be aware of when writing programs, and perhaps the most important thing to be aware of is that implementing abstraction takes a lot of programming time for designing and testing. Balancing these two ideas in a way that meets current requirements and anticipates future requirements is part the art of computer programming (with apologies to Don Knuth!). :)

[reply]

In Section Seekers of Perl Wisdom