On Wed, 2004-09-08 at 03:58, Stefan Behnel wrote:
Just to repeat myself: what really get's slower is runUntilCurrent, but the gain in callLater should compensate that. So, for the case where each callLater leads to a delayed call, the performance gain should be marginal (my patch already avoids shifting the list in linear time) and in all cases where there are more calls to callLater, reset and cancel (added up) than launched delayed calls, I expect the heap implementation to be faster by orders of magnitude.
runUntilCurrent happens every tick; callLater only happens sometimes. Rather than say "average" applications: In my understanding, this will speed up applications that have lots of timed events scheduled at the expense of applications that transfer data over the network. Anthony, if you're listening, do you have a profiling setup that could give us some authoritative numbers?