Re^2: PerlIO slower than traditional IO?

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?

Comment on Re^2: PerlIO slower than traditional IO? Download Code

Replies are listed 'Best First'.
Re^3: PerlIO slower than traditional IO? by pg (Canon) on Aug 15, 2005 at 01:49 UTC
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]
Re^4: PerlIO slower than traditional IO? by biosysadmin (Deacon) on Aug 15, 2005 at 08:37 UTC
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]