[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 mailing list