in reply to Why "Modern Perl" is slower than "Legacy Perl"?

I could not possibly agree more with Tux: “The best way is the way than gets the job done in a manner that the whole team agrees with and is done in a way that the maintainer 5 years from now can still read.   Squeezing out nanoseconds on statements that are only visited once in the lifecycle of a program is useless.”

Moore’s Law still applies ... perhaps now more than ever.   But something else is happening, too:   the hardware upon which our applications might be expected to run (or, that they might be expected to serve) is diversifying.   We don’t live in a world of web-browsers anymore.   We don’t “serve web pages.”   We have no way to know which Pad will come out on top, nor what will follow it.

The “faster” (sic) techniques espoused by older Perls are also older ways, championed at a time when computers (on both the client and the server sides) were much slower and smaller, and the software much less sophisticated.   Software designs today must be, (IMHO) above all other things, “nimble, easily adaptable, and maintainable.”   You need to use the more recently developed techniques.   The “price” that you pay in execution speed is a price that you can well afford to pay.   Attempting to “optimize” it, on the other hand, are a false economy.   I am working long hours right now to try to help rescue a company that stands to lose all of its customers.   (But their program is “fast,” and it runs real good on Netscape 1.0 ...)