[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?

james





More information about the Twisted-Python mailing list