in reply to Re^2: PerlIO slower than traditional IO?
in thread PerlIO slower than traditional IO?

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.

  • Comment on Re^3: PerlIO slower than traditional IO?

Replies are listed 'Best First'.
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!). :)