All the Perl that's Practical to Extract and Report
use Perl Log In
TorgoX (1933)
sburkeNO@SPAMcpan.org
http://search.cpan.org/~sburke/
"Il est beau comme la retractilité des serres des oiseaux rapaces [...] et surtout, comme la rencontre fortuite sur une table de dissection d'une machine à coudre et d'un parapluie !" -- Lautréamont
So you want to go... FASTER?
Somebody wrote to me the other day asking about how/whether they could memoize Locale::Maketext language handles in a mod_perl system they're writing under. I said how (altho the speed benefits are probably miniscule), but I also gave them my standard advice on such matters, which is this:
If you're worrying about page load-times, install mod_gzip before you start fretting over optimizing Perl. Secondly, tell your web designers to buy, read, absorb, and obey Zeldman's book Designing with Web Standards. This is not about fretting over HTML/XHTML distinctions, but about using CSS instead of <table> abominations. Using CSS in new pages/sites, instead of using table hell, will make your HTML saner for the programmers to deal with, and faster for transfer.
I pour myself a cup of strong coffee. :-)
-- Jarkko Hietaniemi
CSS...good! gzip...not so good! (Score:2, Informative)
Yes, embedded tables can cause clients on slow machines to think real hard before rendering the page. Most browsers need to see the end table tag (</table>) before they will display anything on the page. Therefore, if the page can be redesigned so that there are a series of smaller tables, unembedded tables near the top of the page, those tables will be visible on the client-side sooner. This is a good trick to use if you have a giant, spreadsheet-looking thing that you need to generate. CSS can
Re:CSS...good! gzip...not so good! (Score:2, Interesting)
I'm not sure how mod_deflate does it in apache 2.0, though. at any rate, compression is about saving bandwidth and not necessarily about saving client or server resources or speeding up a site.