Re^2: why use OO nature in CGI?

      The OO implementation is faster than the function calls.

That sounds counter intuitive, can you elaborate? Thanks.

Comment on Re^2: why use OO nature in CGI?

Replies are listed 'Best First'.
Re^3: why use OO nature in CGI? by jhourcle (Prior) on May 21, 2005 at 13:36 UTC
Oops...gotta hate when the top of your message directly conflicts with the bottom of the message. I should have said 'may be faster' not 'is faster'. The OO style is less memory intensive. In some situations, especially under mod_perl, the difference can be noticable. There is also, as mentioned in the CGI CGI docs, a little bit of overhead when importing the functions into your namespace that will most likely be more apparent when running shorter scripts. So basically, although the individual method/function calls may be a little bit slower under OO, the overhead it initialization may strip you of that speed. Of course, this goes back to the problem of benchmarks -- someone else's tests may not be representative of your situation, so if you're worried about it, you'd want to run your own tests.	[reply]

Replies are listed 'Best First'.

Re^3: why use OO nature in CGI?
by jhourcle (Prior) on May 21, 2005 at 13:36 UTC

Oops...gotta hate when the top of your message directly conflicts with the bottom of the message.

I should have said 'may be faster' not 'is faster'. The OO style is less memory intensive. In some situations, especially under mod_perl, the difference can be noticable.

There is also, as mentioned in the CGI CGI docs, a little bit of overhead when importing the functions into your namespace that will most likely be more apparent when running shorter scripts.

So basically, although the individual method/function calls may be a little bit slower under OO, the overhead it initialization may strip you of that speed.

Of course, this goes back to the problem of benchmarks -- someone else's tests may not be representative of your situation, so if you're worried about it, you'd want to run your own tests.

[reply]