«

In article <c6n4rf$dcqs0$>,
Gunnar Hjalmarsson <> wrote:
:A benchmark I did showed that CGI.pm required about 0.2 seconds to
:load and parse a simple query string. Do you write CGI apps that take
:20 seconds to execute? I don't.

You either:
a) replace your equipment with faster equipment when you get close to
the 20 second mark; or
b) do not work with expanding amounts of data; or
c) put strict limits on the amount of data that may be stored; or
d) have hypo-sub-log time search routines that you should be sharing
with the theoretical world.

Also, e) you must either not be locking your data, or else you have
worked out ways to guarantee that *all* simultaneous updates will be
completed and the data unlocked in time to make your 20 second window.


Sometimes there's just too much data to process in 20 seconds or less.
--
Preposterous!! Where would all the calculators go?!

Purl Gurl wrote:

> A dynometer displays thirty percent of my Mako's horsepower
> is consumed overcoming friction and inertial mass. So,
> it doesn't matter my wheels are square because this
> loss in efficiency because of my square wheels, is
> nothing in comparsion to my overall horsepower lost
> to all these big picture factors.

Your example is exactly backwards. In any real-world situation, CGI.pm
accounts for 10% or less of a script's overall execution time. Trying to
optimize it is like waxing your square-wheeled 'vette in an attempt to
reduce drag.

Keep in mind, I'm not saying to ignore CGI.pm's weaknesses and use it out of
dogma. All I'm saying is, don't try to prematurely optimize it. Profile
your code to find out where the real bottlenecks are. Fix those, and
profile the code again.

Keep repeating the profile/optimize loop until your boss is screaming at you
to quit being a perfectionist and ship the damn code already. In ten years
of coding Perl for a living, I have yet to see CGI.pm make its way to the
top of the bottleneck list before that happens.

If it does happen, some day, that CGI.pm is the biggest bottleneck, then
I'll worry about writing something faster.

> Would you use CGI.pm to generate html code for a "hello world!" script?

If I were interested in writing a contrived, unrealistic example that did
nothing but "prove" a dubious point, I might do that.

> Your logic is less than Vulcan ideal.

Vulcans are fictional. Short deadlines, limited budgets, and greedy suits
are real.

sherm--

--
Cocoa programming in Perl: http://camelbones.sourceforge.net
Hire me! My resume: http://www.dot-app.org

"Purl Gurl" <> wrote in message
news:...
> Robin wrote:
>
> > Tassilo v. Parseval wrote:
> > > Robin groveled and begged:
> > > > Uri Guttman wrote:
> > > > > Julia deSilva wrote:
>
> (snipped)
>
> > oh, well in that case, I dunno...maybe I gave her too much credit when I
> > first came here. I don't see anything wrong with her code, and i like
her
> > site, but saying that cgi.pm is less functional than insecure cgi parse
code
> > isn't kosher, at least not by my standards.
>
>
> Won't be long you will be another Perl wannabe groupie
> bending the knee, genuflecting and slobbering before
> this Perl Perl Land Cabal around here.
>
>
> Purl Gurl

Ok then.heheh...
Robin

Purl Gurl <> wrote in message news:<>...
> Tassilo v. Parseval wrote:
>
> > Robin wrote:
> > > Uri Guttman wrote:
> > > > Julia deSilva wrote:
>
> (snipped)
>
> > > Who's moronzilla,
>
> > Yes, that's her. She's now writing under the alias Purl Gurl.
>
>
> I do not collect lick and stick gold stars. Nonetheless my
> status is right up there with the best of Perl programmers,
> along with being amongst the best known Perl programmers,
> whether it be fame or infamy.
>
> Shoot, I am even discussed on zdnet and slash dot org!
>
> * Mohammad Cassius Clay Ali voice *
>
> I am the greatest!
>
>
> Purl Gurl * thinks Uri is a mere jabberwockey *

I am truly amazed by your 1337 skillz. If you haven't already done
this, you should make a fanclub for yourself.

LuvU4eva,
DNA.

Walter Roberson wrote:
> Gunnar Hjalmarsson wrote:
>> A benchmark I did showed that CGI.pm required about 0.2 seconds
>> to load and parse a simple query string. Do you write CGI apps
>> that take 20 seconds to execute? I don't.

<snip>

> Sometimes there's just too much data to process in 20 seconds or
> less.

Yes, *sometimes*. But a typical CGI application lets people click on
links or buttons etc. that make the app display generated HTML pages,
and *typically* the total execution time needs to be far, far less
than that (or else the visitors go elsewhere). So, when discussing the
significance of CGI.pm's (lack of) speed, you should reasonably do it
in that context.

--
Gunnar Hjalmarsson
Email: http://www.gunnar.cc/cgi-bin/contact.pl

"Julia deSilva" <> wrote in
newsdrjc.930$:

> Many Congratulations to Robin.
>
> How does this guy (or gal) do it, I mean, how is it possible to take
> such stick, stay cool and come back for more. Many others have got
> themselves into similar situations in this NG and have ended up taking
> offence, being rude, and then getting plonked, or worse.
>
> What a guy ! <sigh>
>
>

I was surprised to see robin still posting.

I don't know why they persist, a troll or just stupid?


I've noticed a pattern with people like Robin, they always think CGI .pm is
too hard and try and make their own. They are always defensive too.

"Bernard R" <> wrote in message
news:Xns94D9A8A2C96D3notrealexamplecome00@194.168. 222.120...
> "Julia deSilva" <> wrote in
> newsdrjc.930$:
>
> > Many Congratulations to Robin.
> >
> > How does this guy (or gal) do it, I mean, how is it possible to take
> > such stick, stay cool and come back for more. Many others have got
> > themselves into similar situations in this NG and have ended up taking
> > offence, being rude, and then getting plonked, or worse.
> >
> > What a guy ! <sigh>
> >
> >
>
> I was surprised to see robin still posting.
>
> I don't know why they persist, a troll or just stupid?
>
>
> I've noticed a pattern with people like Robin, they always think CGI .pm
is
> too hard and try and make their own. They are always defensive too.


I've actually learned cgi.pm now. not to be defensive, but I started out
with my own library and then used cgi.pm.
_Robin

Gunnar Hjalmarsson wrote:

> Yes, *sometimes*. But a typical CGI application lets people click on
> links or buttons etc. that make the app display generated HTML pages,
> and *typically* the total execution time needs to be far, far less
> than that (or else the visitors go elsewhere).

Your argument supports my own. If profiling shows that you're at a point
where CGI.pm is your primary bottleneck, that *is* the appropriate time to
consider either rolling your own or using something else. All I'm saying is
that doing so before you reach that point is a textbook example of
premature optimization, and should be avoided.

> So, when discussing the significance of CGI.pm's (lack of) speed, you
> should reasonably do it in that context.

My main point is that it's inaccurate to simply assume that it will be a
significant bottleneck in all cases. Profile the code and find out.

sherm--

--
Cocoa programming in Perl: http://camelbones.sourceforge.net
Hire me! My resume: http://www.dot-app.org

Purl Gurl wrote:

> Sherm Pendley wrote:
>
>
>>Gunnar Hjalmarsson wrote:
>
>
> (snipped)
>
>
>>>So, when discussing the significance of CGI.pm's (lack of) speed, you
>>>should reasonably do it in that context.
>
>>My main point is that it's inaccurate to simply assume that it will be a
>>significant bottleneck in all cases. Profile the code and find out.
>
>
> Stein's CGI.pm is _always_ a significant bottleneck.

Only for the real wizards: Spot the bottleneck!

use CGI;
sleep(3600);

Thomas (couldn't resist)

--
open STDIN,"<&DATA";$=+=14;$%=50;while($_=(seek( #J~.> a>n~>>e~.......>r.
STDIN,$:*$=+$,+$%,0),getc)){/\./&&last;/\w| /&&( #.u.t.^..oP..r.>h>a~.e..
print,$_=$~);/~/&&++$:;/\^/&&--$:;/>/&&++$,;/</ #.>s^~h<t< ..~. ...c.^..
&&--$,;$:%=4;$,%=23;$~=$_;++$i==1?++$,:_;}__END__#.... >>e>r^..>l^...>k^..

In article <>,
Purl Gurl <> wrote:

> Sherm Pendley wrote:
>
> > Gunnar Hjalmarsson wrote:
>
> (snipped)
>
> > > So, when discussing the significance of CGI.pm's (lack of) speed, you
> > > should reasonably do it in that context.
>
> > My main point is that it's inaccurate to simply assume that it will be a
> > significant bottleneck in all cases. Profile the code and find out.
>
> Stein's CGI.pm is _always_ a significant bottleneck.

In that you generally seem to prefix "CGI.pm" with the name "Stein", you
seem to be indicating that there are other CGI.pm's which we might be
considering. Perhaps you could direct me to one of these other CGI.pm's
so that I could see how it works?

Many thanks,
Ricky

--
Pukku