Beefy Boxes and Bandwidth Generously Provided by pair Networks
No such thing as a small change
 
PerlMonks  

Re: CGI Benchmarks

by colli (Initiate)
on Jan 24, 2001 at 01:22 UTC ( #53809=note: print w/ replies, xml ) Need Help??


in reply to CGI Benchmarks

DON'T USE CGI.PM! It's very slow (it took 50% of the time) Work around: Copy the used subroutines to an seperate Module. That's faster. Colli


Comment on Re: CGI Benchmarks
Re: Re: CGI Benchmarks
by myocom (Deacon) on Jan 24, 2001 at 01:49 UTC

    Disclaimer: I don't regularly use CGI.pm, notably because I do very little web-based work.

    Correct me if I'm wrong, but doesn't CGI.pm do dynamic loading (i.e., if I don't call one of its methods, it doesn't load that bit)? I'd be curious to see your benchmarks that indicate that your separate module was twice as fast as using CGI.pm...

Re: Re: CGI Benchmarks
by extremely (Priest) on Jan 24, 2001 at 03:59 UTC
    Wonderful, we invent a perfectly good way to group code, make it easy to update, and even work together to fix it and get the word out about bad versions so that everyone shares in the benefits...

    Then you come along and ask them to throw that all away over a few paltry microseconds. And chance screwing up the code. And miss out on any redefinition done by other modules through inheritance. And the next time they need to modify the script and just need one more function from CGI they go back to file and try and find it. And they disconnect the functions from the object they work with, potentially breaking all kinds of nice optimizations and friendly features that the full CGI offers. And they wind up pulling over half the module for all the support code anyway and blow off the conditional instantiation so that their code actually winds up bigger in memory.

    Here is a hint for the inexperienced monk, your time spent coding is likely to be millions of times more valuable than the time you will save second-guessing and re-inventing the best modules that Perl has to offer. CGI is so good and so valuable to the Perl community that they stuck it in the core so that everyone has it!.

    --
    $you = new YOU;
    honk() if $you->love(perl)

      I totally agree with you. Let me ask the person who suggested that we not use CGI.pm? Do you have as much experience in Perl as Larrry Wall - obviouslly not. As much as Lincoln Stien? I sincerley doubt it. Then why would you doubt their judgment in including (as extremely said) CGI.pm with the core Perl package? So instead, you would rather waste time copying routines from the CGI module (some of which I have a feeling you know nothing about) into a new module of yours - untested - and use that?

      Listen, the people who write these modules know what they are doing, and the people who decide to include them understand that the benefit of that module will be great on the Perl community, so just trust them. Well, thats my two cents, atleast.

      R.Joseph
Re: Re: CGI Benchmarks
by AgentM (Curate) on Jan 24, 2001 at 08:44 UTC
    Still worried about the time it takes to load CGI? Using a persistent-state-CGI webserver or webserver module is your answer. Because you do have a valid concern, these modules are depended on heavily, are well-tested, and work great! Try FastCGI or mod_perl for more details.
    AgentM Systems nor Nasca Enterprises nor Bone::Easy nor Macperl is responsible for the comments made by AgentM. Remember, you can build any logical system with NOR.

Log In?
Username:
Password:

What's my password?
Create A New User
Node Status?
node history
Node Type: note [id://53809]
help
Chatterbox?
and the web crawler heard nothing...

How do I use this? | Other CB clients
Other Users?
Others drinking their drinks and smoking their pipes about the Monastery: (12)
As of 2014-09-02 13:34 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    My favorite cookbook is:










    Results (22 votes), past polls