Perhaps reframing the problem might give you some insight. It's virtually impossible, on a large system, to "pre-guess" what my performance issues are going to be. I might have an idea of how to improve the speed of a routine by 50%, but if it only takes 1% of the program's total execution time, then my programming time can probably be more profitably spent elsewhere.

Unless you have a known systemic issue (CAD rendering, heavy statistical analysis, etc.) then your time will usually be more profitably spent building the system so that it works to spec. If you have any areas that you suspect will be problematic, take the trouble to properly encapsulate their functionality so it's easier to rework them later. For example, with your hash, create accessor and mutator methods for it. That way, if you later find it too slow, you can take the trouble to re-engineer it but keep the same API. This will reduce that chance of your progam breaking (mind you, this is a good strategy, but doesn't always work in practice).

The important thing is to actually collect hard information to verify where your program is having performance issues. mod_perl is a great choice to improve overall performance, but the triple-nested loop will still scale poorly, regardless of mod_perl. What I would do is get your applications(s) running and then invite people to play it as a beta. Analyze your web logs and find out what programs are being accessed the most frequently (and perhaps parameters passed to them, if applicable). Then, you can use Devel::Dprof and Devel::Smallprof to really dig in and find out exactly what your most expensive sections of code are and work on fine-tuning those.

Hope this helps!

Cheers,
Ovid

Join the Perlmonks Setiathome Group or just click on the the link and check out our stats.