[Twisted-Python] Performance issue in reactor.callLater
James Y Knight
foom at fuhm.net
Wed Sep 8 14:47:15 EDT 2004
On Sep 8, 2004, at 10:37 AM, Stefan Behnel wrote:
> Just to make myself a bit clearer: runUntilCurrent only gets slower
> /per delayed call/. So if there are no delayed calls there should be
> no (measurable) slow down. But if there are delayed calls you will get
> the speed up.
Sounds like the right tradeoff to me.
However, I'm unconvinced about the reasoning in:
> Ok, I thought about it. And I believe the best way to do this is to
> write a specialized heap version. I copied the heapq implementation
> and adapted it so that it keeps track of the position in the heap for
> each DelayedCall. That makes it possible to remove a call without
> linear overhead and in log(N) time.
To me, it seems like the right thing is what I think you had before:
1) on cancel, mark it canceled
2) on delay, mark it delayed
3) when about to run a DelayedCall, if it is cancelled, ignore it. If
it is delayed, reinsert it into the heap in the proper place.
Why did you change to the current method from that?
More information about the Twisted-Python