You could do that by deleting 'CGI.pm' from %INC. You'd then probably get a lot of warnings on redefined subs, so you should rather do something like

delete $INC{'CGI.pm'};
no warnings 'redefine';  # or 'redefined'? Gah, I hate that!
require CGI;
my $cgi = CGI->new;
print OUT $cgi->header;
[download]

Also, CGI->new parses the form parameters, you should take that into account. It's something you probably want to do anyway.

Thanks for the tips. Forcing it to search for CGI.pm every time only makes the print statement 12471% more efficient, but when not using the object-oriented interface, the print statement is 3551% more efficient.

If you had a million hits in one day... 1,000,000 / 24 =~ 41,666 per hour / 60 =~ 694 per minute = 11.5 per second. In my machine both of the options perform at over 6000 operations per second. In order for CGI to become my bottleneck then i would need 518,400,000 hits per day!!!! Yes this assumes a uniform distribution, but the numbers...look at them!! And this is on a PC not a web server and a single one, not a load balanced situation that you should have if you are approaching these kinds of hits. Is yours faster? Yes certainly, but CGI is a well worn tool, it will do what you need now, and down the road it will step up and do things you didn't even know you needed, not bite you in the arse like a hand built solution may.

Use what you want but don't make statments like 12471% more efficient like that is a reason to squeeze this particular piece of code.


___________
Eric Hodges

But according to this test, printing one header by hand is 11331% more efficient than using CGI to do it. Did I miss something?

Two things:

• No useful program will ever print out 100,000 HTTP headers on purpose and exit. That'd be like me benchmarking various ways to roll a cigarette--completely useless because I don't smoke.
• chromatic's second rule of performance optimization: You're doing IO! Microbenchmarks don't matter!

Latency and throughput are much, much more important performance characteristics in such an application, and it's highly unlikely you'll optimize those to the degree that microoptimizations to save milliseconds in program startup time will have any benefit.

The only applicable scenario for this type of optimization is where you're running the program on your own machine and can't run it in a persistent process... but I can't imagine any use for that.

No useful program will ever print out 100,000 HTTP headers on purpose and exit. That'd be like me benchmarking various ways to roll a cigarette--completely useless because I don't smoke.

Obviously not, but it's it's quite likely that the program that prints 1 header will be run 100,000 times. I kind of wish this thread would just die since it keeps costing me experience points, but let me sum up like this: Is "it doesn't take all that long to load" really a good argument to advocate the use of a module? I'm sure CPAN is full of quick loading modules, but why would I use them if I don't need to?

... it's it's quite likely that the program that prints 1 header will be run 100,000 times.

Then why not profile the entire program, including network IO, to see if the cost of loading the module is even significant?

Is "it doesn't take all that long to load" really a good argument to advocate the use of a module?

The real question is "Without actually measuring, is worrying that a module might take too long to load sufficient justification to write my own minimal replacement?"

Question: Why continue to advocate the use of a module that carries the weight of all that extraneous functionality, when it seems that everybody who has any expertise in perl/cgi applications adamantly decries the use of so much of it in favour of templating? Especially when there is a drop-in, cut-down replacement derived from it, that does away with that weight?

---

Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.

"Science is about questioning the status quo. Questioning authority".

In the absence of evidence, opinion is indistinguishable from prejudice.

"Too many [] have been sedated by an oppressive environment of political correctness and risk aversion."

I prefer CGI::Simple as well, but if the choice is between using a core module and writing bizarre and meaningless benchmarks to "prove" that the core module is Just Too Heavy to use, I'll take the core module.

it's not about the microsecond or so it takes to import CGI that matters (because you're going to be using CGI.pm for other things in your CGI script anyway)

Also, using print "some-header: value" is more fragile when exposed to maintenence programmer tampering

Also, is the functional interface to CGI.pm any quicker if you race it too?

And uphill both ways! But according to this test, printing one header by hand is 11331% more efficient than using CGI to do it. Did I miss something?

Yes, you missed something. Two things in fact - "bottleneck" and "profiled". I didn't say I'd benchmarked lots of individual lines of web-apps - I said I'd profiled lots of web-apps! When you profile you find out where the important things to tune are - the really slow things that actually matter. Things like database access, file access, search algorithms, etc. NOT things like CGI.pm!

Benchmarking is a useful tool but it's nearly useless as a way to figure out what's worth spending time optimizing. If you find yourself wanting to disagree then I suggest you stop programming in Perl immediately - C is so much faster! Just try benchmarking:

  for (0 .. 100000) { $a++; }

Versus:

  for (int x = 0; x <= 100000; x++) { a++ }

-sam

When you profile you find out where the important things to tune are - the really slow things that actually matter.

But what if you've already tuned the important things? We're talking about a script that probably won't exceed 30 lines so it's not exactly difficult to maintain.

Benchmarking is a useful tool but it's nearly useless as a way to figure out what's worth spending time optimizing.

Yes, but it is useful in that it tells you how to optimize what you've already decided to optimize. I'd love to write it in C, but 1) I don't know C. and 2) I don't know of any webhost that allows compiled programs without a dedicated server.

But what if you've already tuned the important things?

Then you'd be wasting your time to optimize it further. Optimizing for developer efficiency is just as important (if not more) than optimizing for CPU time!

We're talking about a script that probably won't exceed 30 lines so it's not exactly difficult to maintain.

Ah, the optimism of youth. Trust me, if it's at all useful it will grow. Even if it doesn't grow, someone (maybe you) will copy and paste your nasty hack into a much larger program.

Yes, but it is useful in that it tells you how to optimize what you've already decided to optimize. I'd love to write it in C, but 1) I don't know C.

You should learn C. Then you'll realize that you don't want to write it (or anything) in C unless you absolutely have to. A 30 line Perl program is likely to be 300+ lines of C! The crack about C was meant to be ironic!

-sam

Oh, a few days later, you are asked to add a feature so your app is able to send the content in different languages based on some condition (the contents are ready, you are only asked to deliver them). So, you fixed those lines again and again. And I bet you will surely be very careful about those double EOLs.

Now, tell me, after you implement this with your own, and benchmark it again againsts the CGI.pm version of the same requirement. How much would you gain from the processing time advantage, would it be worth the implementation time?

Simple benchmark won't qualify for the real problem.

And then the next day I decide to automatically generate all of that, so I should use Image::Magick and PDF just to be safe, right?

I'll just have to deal with my future multiple personalities when they start developing. Until then, I'd rather deal with the actual code instead of the theoretical.