-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Wed, Oct 24, 2001 at 05:25:12PM -0400, Scott R. Godin wrote: > Document Path: /testbed/news2.php?executesearch=1 > Document Length: 769 bytes [snip] > Document Path: /cgi-bin/simplesearch.cgi?searchfor=c > Document Length: 698276 bytes
Your site admin apparently needs to be whacked repeatedly with a Clue-by-four (tm). I fail to see how these scripts can possibly be doing the same thing and returning such disparate amounts of data per request. It smells of a somewhat flawed (*cough cough*) benchmark. Even if they were doing the same thing I'd bank on some major misconfiguration on the Perl side. Perl is not C (yet), but it is certainly fast enough. Mind you, I've committed this sin myself once -- benchmarked HTML::Parser versus a regex-based parser I did myself, and concluded that my parser was doing it 11000% faster -- then I noticed the typo in my code that turned the main parse loop into a no-op. You can imagine that a null loop is substantially faster than actual processing :) Fixed that and watched my code drop to second place, 25000% slower. Start by solving the human intelligence issues, *then* work on the Perl issues (if there indeed are any). Having said all that, is this really on topic for dbi-users? - -- Stephen Clouse <[EMAIL PROTECTED]> Senior Programmer, IQ Coordinator Project Lead The IQ Group, Inc. <http://www.theiqgroup.com/> -----BEGIN PGP SIGNATURE----- Version: PGP 6.5.8 iQA/AwUBO9c3ZgOGqGs0PadnEQKfFQCgvKbt5kmg2h1gDh49+qAEOnrc57gAoOtd jKCA+6JmS5YFb6yFsPzGdYay =8fth -----END PGP SIGNATURE-----
