develooper Front page | perl.perl5.porters | Postings from August 2001

Re: [PATCH] C Callbacks, try #3

Thread Previous | Thread Next
From:
Nicholas Clark
Date:
August 24, 2001 12:29
Subject:
Re: [PATCH] C Callbacks, try #3
Message ID:
20010824202948.I41464@plum.flirble.org
On Fri, Aug 24, 2001 at 11:49:53AM -0500, David M. Lloyd wrote:
> As far as the 7%, I suspect that the 'if' condition in my current
> PERL_ASYNC_CHECK() is not as optimizable as the old one, so it ends up
> being more instructions or something.
> 
> By moving the body of the comparison in PERL_ASYNC_CHECK() into a
> function, the 7% disappears but the 35% increases significantly.
> 
> I don't see how I can optimize the empty callback cost any further.  It's
> the function call itself that is slowing things down, as far as I can
> figure out.
> 
> So, this is the question: Is 35% to large a price to pay for the ability
> for more than one function to overload runops?

Am I missing something obvious that prevents this idea working:

As I understand it perl slows down the more operations we do in the
runops loop.
Perl has pluggable runops.

What stops the perl core having 2 or 3 (or 4) runops loops?
A simple runop loop that is the default
A signal checking runop loop that is switched in as soon as anyone sets
anything in %SIG
A signal and callback runop loop that is switched in when the first callback
is registered.
[and maybe a callback no signals loop, but this might be 1 too far]

This would seem to avoid anyone paying the speed penalty for things they
don't need.

NB I don't understand how current pluggable runops works, and how code
indicates to the current op loop that it's time to change, so I may have
missed something obviously stopping my idea.

Nicholas Clark

Thread Previous | Thread Next


nntp.perl.org: Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at ask@perl.org | Group listing | About