On Feb 27, 2013, at 3:55 AM, Peter Westlake <peter.westlake@pobox.com> wrote:

It only makes sense to use ones that have already fired, i.e. defer.succeed(...). 

The problem with only testing synchronously-fired Deferreds is that there are implementation shortcuts possible there, which would allow us to cheat the benchmark.  Granted, it doesn't make sense to do much more work than returning to the reactor - or perhaps not even the reactor, perhaps just a tight outer control loop that does nothing but immediately fire all the Deferreds it knows about when it's returned to - but a not-fired-at-the-time-of-rendering Deferred is a potentially important code path.