The effect of use strict occurs only at compile time, when Perl parses the source code and creates its internal representation. It does not change the execution speed of that code at run time. If the slowdown caused by strict is really a problem, the application can be designed in such a way that the code is only compiled once for a large number of operations. Depending on the application requirements and architecture, there are a number of ways to do this including turning the application into a long-running daemon or running it under mod_perl if it is a web application.
in reply to Re: Re: Re: (OT) Perl Open Source accounting packages?
in thread (OT) Perl Open Source accounting packages?
The big deal if use strict is removed is that it is only a matter of time before somebody decides to try to "fix" a bug in production code without bothering to re-enable strict. When that happens, and it probably will in most deployment environments, the risks of not using strict will far outweigh any potential slowdown from using it.
Besides, in what situation is the speed of an accounting application ever going to be more important that its correctness. I'd much rather have the code dealing with my money protected by the safety afforded by strict than have the code run a little faster.
Update: changed "executions" to "operations" in the first paragraph.