Login | Register For Free | Help
Search for: (Advanced)

Mailing List Archive: ModPerl: ASP

Parser optimisation

 

 

ModPerl asp RSS feed   Index | Next | Previous | View Threaded


dariush at ajax

May 28, 2001, 1:30 AM

Post #1 of 5 (2200 views)
Permalink
Parser optimisation

Hello,
I've noticed that parser uses substitute call for parsing,
changed that and got such results:


New code: 7 wallclock secs ( 7.05 usr + 0.08 sys = 7.13 CPU) @ 14.03/s
(n=100)
Old code: 9 wallclock secs ( 8.45 usr + 0.06 sys = 8.51 CPU) @ 11.75/s
(n=100)
Diff: -2 wallclock secs (-1.40 usr + 0.02 sys = -1.38 CPU)

These are of course over-optimistic - test .asp was more then 5k long,
and I measured just the parsing speed, but hey - any gain in efficency is
good, right?

Here's the diff against ASP.pm
--- /usr/lib/perl5/Apache/ASP.pm Tue Mar 27 21:34:42 2001
+++ ASP.pm Tue May 15 09:24:12 2001
@@ -1085,7 +1085,7 @@

my(@out, $perl_block, $last_perl_block);
$$data .= "<%;;;%>"; # always end with some perl code for parsing.
- while($$data =~ s/^(.*?)\<\%(.*?)\%\>//so) {
+ while($$data =~ /(.*?)\<\%(.*?)\%\>/gso) {
($text, $perl) = ($1,$2);
$perl_block = ($perl =~ /^\s*\=(.*)$/so) ? 0 : 1;
my $perl_scalar = $1;



--
Dariusz Pietrzak
Certified Nobody


---------------------------------------------------------------------
To unsubscribe, e-mail: asp-unsubscribe [at] perl
For additional commands, e-mail: asp-help [at] perl


joshua at chamas

May 28, 2001, 1:38 PM

Post #2 of 5 (2104 views)
Permalink
Re: Parser optimisation [In reply to]

Dariusz Pietrzak wrote:
>
> Hello,
> I've noticed that parser uses substitute call for parsing,
> changed that and got such results:
>
> New code: 7 wallclock secs ( 7.05 usr + 0.08 sys = 7.13 CPU) @ 14.03/s
> (n=100)
> Old code: 9 wallclock secs ( 8.45 usr + 0.06 sys = 8.51 CPU) @ 11.75/s
> (n=100)
> Diff: -2 wallclock secs (-1.40 usr + 0.02 sys = -1.38 CPU)
>
> These are of course over-optimistic - test .asp was more then 5k long,
> and I measured just the parsing speed, but hey - any gain in efficency is
> good, right?
>
> Here's the diff against ASP.pm
> --- /usr/lib/perl5/Apache/ASP.pm Tue Mar 27 21:34:42 2001
> +++ ASP.pm Tue May 15 09:24:12 2001
> @@ -1085,7 +1085,7 @@
>
> my(@out, $perl_block, $last_perl_block);
> $$data .= "<%;;;%>"; # always end with some perl code for parsing.
> - while($$data =~ s/^(.*?)\<\%(.*?)\%\>//so) {
> + while($$data =~ /(.*?)\<\%(.*?)\%\>/gso) {
> ($text, $perl) = ($1,$2);
> $perl_block = ($perl =~ /^\s*\=(.*)$/so) ? 0 : 1;
> my $perl_scalar = $1;
>

I'm not convinced that this does the right thing. If you don't
consume the head of the data, then 2nd,3rd,etc ASP block should
not be picked up correctly. Does a regexp parser know that it
should pick up where it left off from the last match in the string?
I have never seen that behavior documented if it is correct.

Note that you can precompile all the scripts at apache startup in
the parent with Apache::ASP->Loader(), see

http://www.apache-asp.org/tuning.html#Precompile%20Scripts

The point is that all the child httpds don't have to recompile
so you end up with a x MaxClients compiling savings.

--Josh

_________________________________________________________________
Joshua Chamas Chamas Enterprises Inc.
NodeWorks <- Web Link Checking Huntington Beach, CA USA
http://www.nodeworks.com 1-714-625-4051

---------------------------------------------------------------------
To unsubscribe, e-mail: asp-unsubscribe [at] perl
For additional commands, e-mail: asp-help [at] perl


ht000 at foa

May 29, 2001, 12:45 AM

Post #3 of 5 (2112 views)
Permalink
RE: Parser optimisation [In reply to]

...[snip]...
> > - while($$data =~ s/^(.*?)\<\%(.*?)\%\>//so) {
> > + while($$data =~ /(.*?)\<\%(.*?)\%\>/gso) {
>
> I'm not convinced that this does the right thing. If you don't
> consume the head of the data, then 2nd,3rd,etc ASP block should
> not be picked up correctly. Does a regexp parser know that it
> should pick up where it left off from the last match in the string?
> I have never seen that behavior documented if it is correct.

It's documented in L<perlop>:

The /g modifier specifies global pattern matching--that is,
matching as many times as possible within the string. How it
behaves depends on the context. In list context, it returns
a list of the substrings matched by any capturing parentheses
in the regular expression. If there are no parentheses, it
returns a list of all the matched strings, as if there were
parentheses around the whole pattern.

In scalar context, each execution of m//g finds the next
match, returning true if it matches, and false if there
is no further match. The position after the last match
can be read or set using the pos() function; see perlfunc/pos.

I think that it will work.

Henrik Tougaard, FOA, Copenhagen, Denmark.

---------------------------------------------------------------------
To unsubscribe, e-mail: asp-unsubscribe [at] perl
For additional commands, e-mail: asp-help [at] perl


dariush at ajax

May 29, 2001, 2:33 AM

Post #4 of 5 (2114 views)
Permalink
RE: Parser optimisation [In reply to]

> I think that it will work.
Yup, I think I checked that $$data ain't used anywhere else,
and even if it would be, it'd be enough to nullify it and there
would still be noticable speed improvement.

--
Dariusz Pietrzak
Certified Nobody


---------------------------------------------------------------------
To unsubscribe, e-mail: asp-unsubscribe [at] perl
For additional commands, e-mail: asp-help [at] perl


joshua at chamas

May 29, 2001, 10:53 AM

Post #5 of 5 (2101 views)
Permalink
Re: Parser optimisation [In reply to]

Dariusz Pietrzak wrote:
>
> > I think that it will work.
> Yup, I think I checked that $$data ain't used anywhere else,
> and even if it would be, it'd be enough to nullify it and there
> would still be noticable speed improvement.
>

Thanks much for the optimization Dariusz, and showing me the
perlop light Henrik! This optimization will make it
into the next release, 2.11, which will go out this week.

--Josh

_________________________________________________________________
Joshua Chamas Chamas Enterprises Inc.
NodeWorks <- Web Link Checking Huntington Beach, CA USA
http://www.nodeworks.com 1-714-625-4051

---------------------------------------------------------------------
To unsubscribe, e-mail: asp-unsubscribe [at] perl
For additional commands, e-mail: asp-help [at] perl

ModPerl asp RSS feed   Index | Next | Previous | View Threaded
 
 


Interested in having your list archived? Contact Gossamer Threads
 
  Web Applications & Managed Hosting Powered by Gossamer Threads Inc.