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

Re: [PATCH] C Callbacks, try #3

Thread Previous | Thread Next
Paul Johnson
August 24, 2001 14:02
Re: [PATCH] C Callbacks, try #3
Message ID:
On Fri, Aug 24, 2001 at 08:29:48PM +0100, Nicholas Clark wrote:
> 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?

Probably.  But the 7% is definitely too much.  How many modules do you
know which would actually use it?  I know of three.  One is mine, one is
yours, and one is Malcolms.  That's not to say that there aren't more
modules out there using pluggable runops, or that people wouldn't find a
good use for these callbacks if we get it right, but I just wanted to
emphasise that any slowdown at all in the common case is probably

> 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.

Only that the main call to runops doesn't exit until the end of the
program, so you setup your new runops function at the start, and that's
the one you run.

There was some discussion on #perl a few days ago about lexically scoped
runops functions which didn't seem to come up against any compelling
reasons why this couldn't or shouldn't be done.

Paul Johnson -

Thread Previous | Thread Next Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at | Group listing | About