On Sat, 26 Jan 2002, Perrin Harkins wrote: >> It all depends on what kind of application do you have. If you code >> is CPU-bound these seemingly insignificant optimizations can have a >> very significant influence on the overall service performance. > > Do such beasts really exist? I mean, I guess they must, but I've > never seen a mod_perl application that was CPU-bound. They always > seem to be constrained by database speed and memory.
I've seen one. However, it was much like a normal performance problem - the issue was with one loop which ran one line which was quite pathological. Replacing loop with an s///eg construct eliminated the problem; there was no need for seemlingly insignificant optimizations. (Actually, the problem was *created* by premature optimization - the coder had utilized code that was more efficient than s/// in one special case, to handle a vastly different instance.) However, there could conceivably be code which was more of a performance issue, especially when the mod_perl utilizes a very successful cache on a high traffic site. >> On the other hand how often do you get a chance to profile your code >> and see how to improve its speed in the real world. Managers never >> plan for debugging period, not talking about optimizations periods. Unless there's already a problem, and you have a good manager. We've had a couple of instances where we were given time (on the schedule, before the release) to improve speed after a release. It's quite rare, though, and I've never seen it for a mod_perl project. Ed
