[Twisted-Python] Performance issue in reactor.callLater

Stefan Behnel behnel_ml at gkec.informatik.tu-darmstadt.de
Mon Sep 6 13:53:26 EDT 2004

Bob Ippolito schrieb:
> There's also the fact that this:
> def infiniteLoop():
>     reactor.callLater(0.0, infiniteLoop)
> will just destroy Twisted because the current loop iteration will never 
> finish.
> In my non-Twisted implementation of the same concept, during each 
> iteration I keep a list of new timers, which gets merged into the heap 
> at the end of each iteration (so that they will be in the heap for the 
> next round).

I think that's the way to go. That's actually easy to do, here's a patch against my implementation that does exactly that. It moves a bit more work into runUntilCurrent, but I think I already made my point in that regard.

> I'm not sure I understand the logic behind _cleanUpCallLater in the 
> patch?  It doesn't seem right, especially for delayed, but I didn't 
> really read very carefully.

In the cancelled case, it just pops the cancelled call - done (and obviously correct). In the delayed case it pops the changed call (that possibly temporarily brakes the heap invariant) and replaces it with itself, so it actually re-inserts the call at the right position.

Though, ... I guess I do see a problem if the value of a call somewhere in the heap is changed. That brakes the heap invariant and may conflict with further changes to the heap. Let me think about it.


-------------- next part --------------
A non-text attachment was scrubbed...
Name: base.py+merge_later.diff
Type: text/x-patch
Size: 1163 bytes
Desc: not available
Url : http://twistedmatrix.com/pipermail/twisted-python/attachments/20040906/6c8479fd/attachment.bin 

More information about the Twisted-Python mailing list