A1 Triple Gold Star for Robin

[Julia deSilva]

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>

 

[Uri Guttman]

Jd> Many Congratulations to Robin.

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

he is too dumb to know better? notice he seems to think moronzilla has a
clue.

uri

 

[Robin]

Jd> Many Congratulations to Robin.

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

he is too dumb to know better? notice he seems to think moronzilla has a
clue.

hahaha....yeah, that's it. Who's moronzilla, can you point me in the
direction of the post(s) I replied to or the information your refering to? I
remember trawling this group two years ago and reading some posts by
godzilla, is that who you mean?

-Robin

 

[Robin]

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>

Thanks julia! Much appreciated.
-Robin

 

[Tassilo v. Parseval]

Also sprach Robin:

hahaha....yeah, that's it. Who's moronzilla, can you point me in the
direction of the post(s) I replied to or the information your refering to? I
remember trawling this group two years ago and reading some posts by
godzilla, is that who you mean?

Yes, that's her. She's now writing under the alias Purl Gurl.

Tassilo

 

[Tad McClellan]

Nonetheless my
status is right up there with the best of Perl programmers,

Bullshit.

 

[Tore Aursand]

I do not collect lick and stick gold stars. Nonetheless my status is
right up there with the best of Perl programmers,

Where? I can't see you?!

 

[Sherm Pendley]

site, but saying that cgi.pm is less functional than insecure cgi parse
code isn't kosher, at least not by my standards.

What she actually said was that CGI.pm is slower, and as far as that goes
she's right. It's a heavy weight module. A more modular approach, with CGI,
HTML, and Cookie functions in separate modules, would have been better than
the AllPurposeWebThing.pm that CGI.pm has grown into - but that's an old
argument.

The problem is that she was looking at CGI.pm vs. hand-rolled code in
isolation, and that's simply not a realistic scenario. In any real-world
app, the time spent processing the main body of the code will *completely*
dwarf that spent parsing the form input.

Just do the math.

Let's say profiling (with Devel:Prof) shows you that 1% of your overall
execution time is spent in CGI.pm, while 20% of it is spent in foo(). If
you can improve the efficiency of foo() by just 3%, to 19.4% of the overall
total, you've done more for the overall total than you would have by
cutting the cost of CGI.pm in half. If you can cut the cost of foo() in
half, you've done *far* more for the bottom line than *any* amount of work
on CGI.pm could possibly do.

In principle, we'd all be optimizing every last line of code to its peak
efficiency. Unfortunately, we just don't have time for that, so we have to
spend the time we do have where it will make the most difference.

At the same time she does have a lot of good stuff to say.

She's funny, I'll give her that.

sherm--

 

[Gunnar Hjalmarsson]

Just do the math.

Let's say profiling (with Devel:Prof) shows you that 1% of your
overall execution time is spent in CGI.pm, while 20% of it is spent
in foo(). If you can improve the efficiency of foo() by just 3%, to
19.4% of the overall total, you've done more for the overall total
than you would have by cutting the cost of CGI.pm in half. If you
can cut the cost of foo() in half, you've done *far* more for the
bottom line than *any* amount of work on CGI.pm could possibly do.

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. And in that case your example is not
realistic. CGI.pm's inefficiency is apparently worse than you thought.

 

[Robin]

Also sprach Robin:


Yes, that's her. She's now writing under the alias Purl Gurl.

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.
At the same time she does have a lot of good stuff to say.
-Robin

 

[Walter Roberson]

: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.

 

[Sherm Pendley]

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--

 

[Robin]

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

 

[Daniel N. Andersen]

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.

 

[Gunnar Hjalmarsson]

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.

 

[Bernard R]

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.

 

[Robin]

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

 

[Sherm Pendley]

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--

 

[Thomas Kratz]

Sherm Pendley wrote:





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)

 

[Richard Morse]

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