Take Stream.pm as one example, its slowness should ring the bell.

I want to say that I don't think that Stream.pm is "slow". But I don't know what you think you mean, so I cannot contradict you. After three years of teaching performance tuning classes at OSCON, the one thing I am sure I have learned from my research is that people are much too eager to say it's "too slow" when they don't really know what they mean by it.

For example, you might mean that it is slower than using arrays. But it doesn't do the same thing as arrays, so there is no reason to expect it to be as fast as arrays. Perl arrays are slower than C arrays. This is not a defect in Perl arrays. Perl arrays were not supposed to be as fast as C arrays; they were supposed to support push.

Another thing I learned from my research for the classes is that people pronounce things "slow" or "fast" without doing proper research, and with no regard for the real facts. Even when they do the research, benchmarking a tricky business. The tools are bad, and they are easy to misuse. One whole section of my class is nothing but examples of benchmarks that were written incorrectly and led the writer to the wrong conclusion. Some of those examples come from Perlmonks.

One more point occurs to me. This is that the techniques in my book are primarily based around using functions. If the techniques are slower than other techniques, it is probably because they call a lot of functions. If function calls are slow, that is not a problem with the techniques; it is a problem with the language implementation. Function calling is not a frill that you can avoid when you want extra speed; it is essential. Every program makes lots of function calls. Avoiding function calls because they are slow is an absurd response to performance problems. If Perl's function calls are slow, the right response is to try to fix the implementation, not to try to avoid function calls.