This actually points to a deeper issue, which is premature optimization. Are you truly conscious of the users sitting, looking at a blank page for a while? Or, are you thinking that there could be a problem and want to head it off at the pass? Remember, WWW users are really forgiving, especially if the page will be doing a lot of looking-things-up for them. Any page that loads in under 5 seconds is considered standard. If it consistently loads in under 1-2 seconds, then that's spectacular. (Orbitz and Google come to mind.) Anything over 5 seconds runs the risk of losing their attention. (Flash pages are a big culprit in this category.)

If you are, then have you profiled the entire request, looking for the spot that takes the longest? In 99.999% of the cases where I have had to optimize a CGI request, the culprit has always been either the SQL statement or my handling of the result. Very simple optimizations that provide anywhere from 10%-50% speedup include:

• Using prepare_cached() for inner selects
• Unrolling loops from Perl into SQL
• Moving decision points to SQL, reducing the size of the result set
• Using bind_columns() and fetch() (just like DBI suggests ... fetchrow_hashref() is one of the slower ways to get your result set ...)

Also, regarding buffered output to CGI ... you want your output to be buffered. In fact, you (almost always) never want anything to be sent to the user until you have the entire page assembled. Think about it this way - if you send half the page, then hit an error, you now have a user who thinks your site is stupid, cause it only gave it half the page. However, if you wait until you know the entire page, you can display only that which you want the users to see.

Remember - most programming is (should be?) about handling error conditions. Most displays that are built (should?) have to do with error conditions. Users want to know when something went wrong. They don't want to be lulled into a false sense of security. Think about it this way - if your online banking site didn't tell you when a scheduled payment couldn't go through (for whatever reason), you'd be pretty pissed, right? (I have run into that one ...)

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

The idea is a little like C++ templates, except not quite so brain-meltingly complicated. -- TheDamian, Exegesis 6

Please remember that I'm crufty and crochety. All opinions are purely mine and all code is untested, unless otherwise specified.