[Twisted-Python] Performance issue in reactor.callLater
Stefan Behnel
behnel_ml at gkec.informatik.tu-darmstadt.de
Mon Sep 6 11:53:26 MDT 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.
Stefan
-------------- 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: </pipermail/twisted-python/attachments/20040906/6c8479fd/attachment-0002.bin>
More information about the Twisted-Python
mailing list