Re^2: Profiling/Benchmarking web applications.

Are you suggesting optimizing non-profiled code? While experience usually helps you identify bottlenecks with mere eye-grep, you'd better not encourage others to do the same.

One of the most strong laws of performance tuning is: never ever even think of optimizing before profiling. You just gonna spend your time on the code that could potentially not affect performance at all. And you usually skip those things that are considered fast and quick, but in fact suck. You probably know about those gotchas with Cache::SharedMemoryCache or HTML::Template's global_vars. Weren't they surprises? Just examples of how important profiling is (and how rarely it is really carried on).

Comment on Re^2: Profiling/Benchmarking web applications.

Replies are listed 'Best First'.
Re^3: Profiling/Benchmarking web applications. by dragonchild (Archbishop) on Aug 25, 2004 at 17:44 UTC
You are absolutely correct - nothing is a substitute for good profiling, and everyone should become familiar with ways of profiling their application. (The same goes for testing, too.) However, there are certain constructs which are known to be performance hogs. For example, using `$sth->fetchall_arrayref({});` is practically the slowest way to get data from a database, when compared with other methods. Another is H::T's global_vars, as you mentioned. These don't need to be profiled because they are known performance hits. I would suggest merging our two approaches. Setting up a good profiling scenario can be time-consuming. In my experience, tackling the usual suspects has almost always provided enough improvement without needing to do a full profiling of a webapp. However, after hitting the usual suspects, profiling is most definitely the way to go. And, frankly, I'm not surprised that output generation is expensive. But, I suspect that most webapps are getting bogged down in other areas. ------ We are the carpenters and bricklayers of the Information Age. Then there are Damian modules.... sigh* ... that's not about being less-lazy -- that's about being on some really good drugs -- you know, there is no spoon.* - flyingmoose I shouldn't have to say this, but any code, unless otherwise stated, is untested	[reply] [d/l]

Replies are listed 'Best First'.

Re^3: Profiling/Benchmarking web applications.
by dragonchild (Archbishop) on Aug 25, 2004 at 17:44 UTC

However, there are certain constructs which are known to be performance hogs. For example, using $sth->fetchall_arrayref({}); is practically the slowest way to get data from a database, when compared with other methods. Another is H::T's global_vars, as you mentioned. These don't need to be profiled because they are known performance hits.

I would suggest merging our two approaches. Setting up a good profiling scenario can be time-consuming. In my experience, tackling the usual suspects has almost always provided enough improvement without needing to do a full profiling of a webapp.

However, after hitting the usual suspects, profiling is most definitely the way to go. And, frankly, I'm not surprised that output generation is expensive. But, I suspect that most webapps are getting bogged down in other areas.

------
We are the carpenters and bricklayers of the Information Age.

Then there are Damian modules.... *sigh* ... that's not about being less-lazy -- that's about being on some really good drugs -- you know, there is no spoon. - flyingmoose

I shouldn't have to say this, but any code, unless otherwise stated, is untested

[reply]
[d/l]