Beefy Boxes and Bandwidth Generously Provided by pair Networks
Do you know where your variables are?

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

Replies are listed 'Best First'.
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 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) 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.

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.
Re: Re: CGI Benchmarks
by myocom (Deacon) on Jan 24, 2001 at 01:49 UTC

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

    Correct me if I'm wrong, but doesn't 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

Log In?

What's my password?
Create A New User
Node Status?
node history
Node Type: note [id://53809]
[Corion]: Discipulus: Hahaha ;)
[Discipulus]: marioroy did you know zentara is back to themonastery? he was used to be one of the best parallel programming monks

How do I use this? | Other CB clients
Other Users?
Others studying the Monastery: (9)
As of 2017-03-23 08:33 GMT
Find Nodes?
    Voting Booth?
    Should Pluto Get Its Planethood Back?

    Results (285 votes). Check out past polls.