benchmark for inlineCallbacks
Bug #1108197 reported by
Glyph Lefkowitz
This bug affects 1 person
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
Twisted Benchmarks |
New
|
Undecided
|
Unassigned |
Bug Description
There are some potential performance problems with inlineCallbacks, as documented on <http://
To post a comment you must log in.
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 `inlineCallback s`-decorated function? s`-decorated function? s`-decorated function?
* How much does it cost to return a result from an `inlineCallback
* How much does it cost to context switch away from and then back into an `inlineCallback
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-`inlineCall backs`- 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.).