You are viewing a plain text version of this content. The canonical link for it is here.
Posted to modperl@perl.apache.org by Stas Bekman <st...@stason.org> on 2003/03/25 00:41:59 UTC
speeding up CGI.pm
While we are at the CGI.pm issue, I was thinking that those who stick with
CGI.pm because of its extended all-in-one functionality (request parsing/ HTML
generation), but unhappy about request parsing speed, could benefit by
integrating Apache::Request in CGI.pm to do the request parsing. So if
Apache::Request is available CGI.pm could re-alias its args(), params(), etc.
functions to call Apache::Request functions instead. What do you think?
__________________________________________________________________
Stas Bekman JAm_pH ------> Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide ---> http://perl.apache.org
mailto:stas@stason.org http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
Re: speeding up CGI.pm
Posted by Ask Bjoern Hansen <as...@develooper.com>.
On Tue, 25 Mar 2003, Stas Bekman wrote:
[...]
> > http://marc.theaimsgroup.com/?l=apache-modperl&m=95587404903236&w=2
>
> If something can be made faster with very little effort, why not doing that?
Often because the cost of having to deal with the increased
complexity and new obscure bugs isn't worth it.
- ask
--
ask bjoern hansen, http://www.askbjoernhansen.com/ !try; do();
Re: speeding up CGI.pm
Posted by Stas Bekman <st...@stason.org>.
Gunther Birznieks wrote:
>
> Stas Bekman wrote:
>
>> While we are at the CGI.pm issue, I was thinking that those who stick
>> with CGI.pm because of its extended all-in-one functionality (request
>> parsing/ HTML generation), but unhappy about request parsing speed,
>> could benefit by integrating Apache::Request in CGI.pm to do the
>> request parsing. So if Apache::Request is available CGI.pm could
>> re-alias its args(), params(), etc. functions to call Apache::Request
>> functions instead. What do you think?
>
>
> From an outsider's perspective, I agree.
>
> For some previous discussion (April 16, 2000)
>
> http://marc.theaimsgroup.com/?l=apache-modperl&m=95587404903236&w=2
If something can be made faster with very little effort, why not doing that?
Certainly the degree of performance improvement depends on how heavy the
request parsing is, but you get a better speed overall.
__________________________________________________________________
Stas Bekman JAm_pH ------> Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide ---> http://perl.apache.org
mailto:stas@stason.org http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
Re: speeding up CGI.pm
Posted by Gunther Birznieks <gu...@extropia.com>.
Stas Bekman wrote:
> While we are at the CGI.pm issue, I was thinking that those who stick
> with CGI.pm because of its extended all-in-one functionality (request
> parsing/ HTML generation), but unhappy about request parsing speed,
> could benefit by integrating Apache::Request in CGI.pm to do the
> request parsing. So if Apache::Request is available CGI.pm could
> re-alias its args(), params(), etc. functions to call Apache::Request
> functions instead. What do you think?
From an outsider's perspective, I agree.
For some previous discussion (April 16, 2000)
http://marc.theaimsgroup.com/?l=apache-modperl&m=95587404903236&w=2
>
Re: speeding up CGI.pm
Posted by Stas Bekman <st...@stason.org>.
Lincoln Stein wrote:
> I like the idea of that, although the handsprings needed to do ordinary CGI,
> mp1 and mp2 might lead to a cloud of confusion. Best to keep them in
> separate modules and load them into CGI as needed.
This should be absolutely transparent from the user's point of view.
BTW, my post was regarding mp1, since Apache::Request is available for mp1.
Once Apache::Request is available for mp2, it can be integrated as well.
Hopefully it's Perl API won't change, so CGI.pm will probably not need to be
changed as well.
> Is Apache::Request in mp2 ready for prime time? We haven't been able to get
> it running here (some sort of install problem, my people tell me).
No, it's totally rewritten to accomodate the new Apache API, and also changed
the internal design. However it's not completed yet.
> On Tuesday 25 March 2003 03:25 am, Issac Goldstand wrote:
>
>>That would be really amazing if it could still be implemented in mp1, too,
>>as it would allow for interoperability between libapreq-based applications
>>(like Apache::UploadMeter) and response handlers like CGI scripts which use
>>CGI.pm I suppose that this isn't such a big problem in mp2 whose filters
>>will probably make using one API for request handling unnecessary...
>>
>> Issac
>>
>>----- Original Message -----
>>From: "Stas Bekman" <st...@stason.org>
>>To: <ls...@cshl.org>; <mo...@perl.apache.org>
>>Sent: Tuesday, March 25, 2003 1:41 AM
>>Subject: speeding up CGI.pm
>>
>>
>>>While we are at the CGI.pm issue, I was thinking that those who stick
>>>with CGI.pm because of its extended all-in-one functionality (request
>>>parsing/
>>
>>HTML
>>
>>
>>>generation), but unhappy about request parsing speed, could benefit by
>>>integrating Apache::Request in CGI.pm to do the request parsing. So if
>>>Apache::Request is available CGI.pm could re-alias its args(), params(),
>>
>>etc.
>>
>>
>>>functions to call Apache::Request functions instead. What do you think?
>>>
>>>__________________________________________________________________
>>>Stas Bekman JAm_pH ------> Just Another mod_perl Hacker
>>>http://stason.org/ mod_perl Guide ---> http://perl.apache.org
>>>mailto:stas@stason.org http://use.perl.org http://apacheweek.com
>>>http://modperlbook.org http://apache.org http://ticketmaster.com
>>
>
--
__________________________________________________________________
Stas Bekman JAm_pH ------> Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide ---> http://perl.apache.org
mailto:stas@stason.org http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
Re: speeding up CGI.pm
Posted by Nick Tonkin <ni...@tonkinresolutions.com>.
On Tue, 25 Mar 2003, Lincoln Stein wrote:
> I like the idea of that, although the handsprings needed to do ordinary CGI,
> mp1 and mp2 might lead to a cloud of confusion. Best to keep them in
> separate modules and load them into CGI as needed.
>
> Is Apache::Request in mp2 ready for prime time? We haven't been able to get
> it running here (some sort of install problem, my people tell me).
Not at all ready. I do not believe even a beta release has been made.
- nick
--
~~~~~~~~~~~~~~~~~~~~
Nick Tonkin {|8^)>
Re: speeding up CGI.pm
Posted by Lincoln Stein <ls...@cshl.org>.
I like the idea of that, although the handsprings needed to do ordinary CGI,
mp1 and mp2 might lead to a cloud of confusion. Best to keep them in
separate modules and load them into CGI as needed.
Is Apache::Request in mp2 ready for prime time? We haven't been able to get
it running here (some sort of install problem, my people tell me).
Lincoln
On Tuesday 25 March 2003 03:25 am, Issac Goldstand wrote:
> That would be really amazing if it could still be implemented in mp1, too,
> as it would allow for interoperability between libapreq-based applications
> (like Apache::UploadMeter) and response handlers like CGI scripts which use
> CGI.pm I suppose that this isn't such a big problem in mp2 whose filters
> will probably make using one API for request handling unnecessary...
>
> Issac
>
> ----- Original Message -----
> From: "Stas Bekman" <st...@stason.org>
> To: <ls...@cshl.org>; <mo...@perl.apache.org>
> Sent: Tuesday, March 25, 2003 1:41 AM
> Subject: speeding up CGI.pm
>
> > While we are at the CGI.pm issue, I was thinking that those who stick
> > with CGI.pm because of its extended all-in-one functionality (request
> > parsing/
>
> HTML
>
> > generation), but unhappy about request parsing speed, could benefit by
> > integrating Apache::Request in CGI.pm to do the request parsing. So if
> > Apache::Request is available CGI.pm could re-alias its args(), params(),
>
> etc.
>
> > functions to call Apache::Request functions instead. What do you think?
> >
> > __________________________________________________________________
> > Stas Bekman JAm_pH ------> Just Another mod_perl Hacker
> > http://stason.org/ mod_perl Guide ---> http://perl.apache.org
> > mailto:stas@stason.org http://use.perl.org http://apacheweek.com
> > http://modperlbook.org http://apache.org http://ticketmaster.com
--
========================================================================
Lincoln D. Stein Cold Spring Harbor Laboratory
lstein@cshl.org Cold Spring Harbor, NY
========================================================================
Re: speeding up CGI.pm
Posted by Issac Goldstand <ma...@beamartyr.net>.
That would be really amazing if it could still be implemented in mp1, too,
as it would allow for interoperability between libapreq-based applications
(like Apache::UploadMeter) and response handlers like CGI scripts which use
CGI.pm I suppose that this isn't such a big problem in mp2 whose filters
will probably make using one API for request handling unnecessary...
Issac
----- Original Message -----
From: "Stas Bekman" <st...@stason.org>
To: <ls...@cshl.org>; <mo...@perl.apache.org>
Sent: Tuesday, March 25, 2003 1:41 AM
Subject: speeding up CGI.pm
> While we are at the CGI.pm issue, I was thinking that those who stick with
> CGI.pm because of its extended all-in-one functionality (request parsing/
HTML
> generation), but unhappy about request parsing speed, could benefit by
> integrating Apache::Request in CGI.pm to do the request parsing. So if
> Apache::Request is available CGI.pm could re-alias its args(), params(),
etc.
> functions to call Apache::Request functions instead. What do you think?
>
> __________________________________________________________________
> Stas Bekman JAm_pH ------> Just Another mod_perl Hacker
> http://stason.org/ mod_perl Guide ---> http://perl.apache.org
> mailto:stas@stason.org http://use.perl.org http://apacheweek.com
> http://modperlbook.org http://apache.org http://ticketmaster.com
>