Re: arrange form data in same order as on form
From: Gunnar Hjalmarsson (noreply_at_gunnar.cc)
Date: 11/18/03
- Next message: Tore Aursand: "Re: extract block of text"
- Previous message: Ben Morrow: "Re: extract block of text"
- In reply to: Alan J. Flavell: "Re: arrange form data in same order as on form"
- Next in thread: Eric J. Roode: "Re: arrange form data in same order as on form"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Date: Tue, 18 Nov 2003 02:42:02 +0100
Alan J. Flavell wrote:
> Gunnar Hjalmarsson wrote:
>> If I didn't make some stupid mistake, the comparison shows that
>> the compilation+execution time for parsing a simple query string
>> with 4 name/value pairs is about 30 times longer when you use
>> CGI.pm compared to my code. CGI.pm needs about 0.2 seconds!
>
> And how long does a typical do-nothing browser HTTP transaction and
> CGI invocation need in comparison?
<snip>
> the need is to review the overall process, including server
> invocation from the client and the subsequent CGI process creation,
> which I'm afraid your benchmarks don't do.
What the need is depends on what you are actually trying to measure.
The conclusion I make out from my benchmark is that the *absolute*
time it takes to parse a query string is significant if you use
CGI.pm, while it's negligible if you use my code. Whether the factor
is 20, 30 or 50 is something I pay little regard to since, as you
point out, I did not measure the whole process.
My program supports a certain kind of web application, and is
typically used on web sites that are hosted on shared servers.
Sometimes it's used in a way that results in thousands of calls per day.
Now, if you have a busy web site on a shared hosting account, there is
always a limit where the hosting provider says: "This is too much, our
other cusomers are affected adversely." That's why I'm anxious to
watch the server load, and to me, 0.2 seconds appears to be
significant if there are thousands of daily calls.
mod_perl is of course suitable in order to further reduce the server
load. It's just that it's very unusual that mod_perl is availabe on
shared web hosting accounts. Of course, you can always say that the
program should have been written in PHP instead. However, that's not
the case.
> In fact with some rough benchmarking of the overall process (using
> LWP::Simple to run the tests against a local webserver), it seemed
> to me as if our (otherwise lightly-loaded) server could run about
> 14 invocations per second of wallclock with your economy-model
> script, compared with some 7 per second with CGI.pm, so - a factor
> of around 2 (wallclock) overall, compared with your measurement of
> 30 (cpu) for some portion of the process. On Windows, I even got a
> factor approaching 3 between them for the overall process. (Server
> in both cases was a version of Apache 1.3.*, on linux and on
> Win2000 respectively).
>
> While I must admit the factor is somewhat larger than I had
> expected, this does rather put your measurement of a factor of 30
> into a rather more realistic context, I feel.
As regard "realistic", see above.
It surprises me that your server would allow 7 invocations per second
with CGI.pm when you run the whole process, while I found that it
would allow 5 times when only the Perl part is taken into account.
Maybe the server you used is significantly faster. Btw, are you sure
that you captured the compilation time?
Anyway, this is interesting additional info. Thanks, Alan! I suppose
it indicates that, provided that the factor is 2, I would double the
server load by starting to use CGI.pm. The difference appears to be
significant also when you look at it from this angle.
These benchmarks demonstrate that the design of CGI.pm is surprisingly
'expensive'.
> I will concede that any rule can have exceptions. What I usually
> say about CGI.pm is that those who have genuinely got the expertise
> to *not* use CGI.pm will know why they are doing that, and will
> need no advice from me. On the other hand anyone who's in a
> position to seek advice is going to get my best advice (and you
> know what that's going to be, in the overwhelming proportion of
> cases).
>
> I'm clearly aware that CGI.pm is in no way magical - the code
> doesn't do anything that one couldn't just as well code for
> oneself. And the author admits that it's grown too big, and might
> benefit from being modularised. I've found the odd bug in it
> myself on occasion. So this is not the uncritical adulation that
> some trolls accuse us of. Nevertheless, it's overall the best thing
> available for doing CGI in Perl, because the author is actively
> working on it and is actively adapting it to the changing
> situation, to encapsulate the gathered knowledge of browser bugs,
> workarounds etc.
>
> A proportion of extra CPU cycles isn't usually too high a price to
> pay for that. And as we've seen - if it _is_ too high a price to
> pay, then the most productive place to make real savings is
> elsewhere.
>
> Can we call a truce on this, then?
I hear what you say. :) And it makes much sense.
Let me try to summarize my view on it out from a different angle:
Good advice is a good thing, and using Perl modules is a convenient
way to reuse code. Personally I use several modules, but when I'm able
to do something with just a couple of lines of Perl code, I sometimes
do so instead of loading hundreds of lines of code by using a module.
I don't feel that I risk getting bashed for doing so, and nobody
demands that I *prove* that my choices are right.
That is, there is one exception: The 'sacred cow' CGI.pm. Even if you
say that "the code doesn't do anything that one couldn't just as well
code for oneself" and "it's grown too big", your reasoning above
presupposes that you are able to explicitly justify your decision if
you choose to not use CGI.pm for parsing CGI data. That makes little
sense to me. The presumption that people don't know what they are
doing if they don't use CGI.pm is patronizing.
If the explanation is the security implications with CGI, I'd like to
see the focus moved to the desirable that you
- *learn* about the implied risks with CGI scripts,
- don't use code copied from random sources if you don't understand
how it works,
- carefully consider the risks with your own applications, and
validate the data accordingly, and
- enable taint mode.
I feel that these things, which I take for granted that we can agree
upon, tend to be forgotten in the 'campaign' for using CGI.pm.
-- Gunnar Hjalmarsson Email: http://www.gunnar.cc/cgi-bin/contact.pl
- Next message: Tore Aursand: "Re: extract block of text"
- Previous message: Ben Morrow: "Re: extract block of text"
- In reply to: Alan J. Flavell: "Re: arrange form data in same order as on form"
- Next in thread: Eric J. Roode: "Re: arrange form data in same order as on form"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Relevant Pages
|
|
