benchmark for inlineCallbacks

Bug #1108197 reported by Glyph Lefkowitz
This bug affects 1 person
Affects Status Importance Assigned to Milestone
Twisted Benchmarks

Bug Description

There are some potential performance problems with inlineCallbacks, as documented on <>, but no benchmarks exist to validate any possible fixes. We should have such a benchmark.

Revision history for this message
Jean-Paul Calderone (exarkun) wrote :

I wonder which benchmarks would be interesting. I can think of some possibilities.

  * How much does it cost to raise an unhandled exception out of an `inlineCallbacks`-decorated function?
  * How much does it cost to return a result from an `inlineCallbacks`-decorated function?
  * How much does it cost to context switch away from and then back into an `inlineCallbacks`-decorated function?

It seems like there may be a straightforward way to benchmark the first two of these. The absolute results of those benchmarks may not be very interesting, but results over time should be a good metric for ourselves as far as avoiding significant performance regressions or evaluating proposed optimizations. It might be nice if these results could somehow be compared to the equivalent non-`inlineCallbacks`-based code, but I'm not sure how feasible that really is (at least, given our current benchmarking infrastructure).

I'm not sure how to best write the third benchmark. Should we use something like `deferLater(reactor, 0, ...)` as a way to synthesize minimal-overhead context switches? While that may indeed be "minimal", it's probably not quite "low". Maybe that's fine? Or at least a good enough start? Possibly it won't be clear unless someone implements; then we can compare its results to the "iteration" bechmark - if the results are not very different, then that might not be a very interesting thing to measure (... except as a way to avoid a regressions that *makes* the results very different? Hrmph.).

To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers