Twisted Deferred.addCallBack() vs. yield and @inlineDeferred

Question

Is there any reason to use one over the other?

Do they have the same performance?

Answer 1

The differences should really be subtle. If this code really does run that often that it matters, perhaps you should look into your application design. Otherwise, take the variant which is more easy to read, you will have to make heads and tails out of it a couple of months or years down the road.

EDIT: If you really want to know, here is how you find out (it could, after all, be implementation specific to your python version): run both version in a tight loop and measure the time. Increase loop count until the time difference between the versions is far greater than the time variance of the same version across multiple runs. Repeat after changing python version, OS etc.

Answer 2

I tend to use inlineCallbacks for multistep initialization (such as auth) to some service where each subsequent step depends on a result from the previous step, for example. Other than these situations, I tend to find that inlineCallbacks could lead to lazy programming that could slow down your app.

Here's an example:

@defer.inlineCallbacks
def some_func():
    res1 = yield call1()
    res2 = yield call2()
    ... do something with res1 and res2 ...

If call1 and call2 are completely independent calls that you want to parallelize, this function will end up serializing those calls. To convert this to a parallelizing call you should:

@defer.inlineCallbacks
def some_func_better():
    d1 = call1()
    d2 = call2()
    res1 = yield d1
    res2 = yield d2

This way you get call1 and call2 running simultaneously, but you wait on the results as they come in. So, while it's possible to get the same benefits out of stock deferreds, it seems inlineCallbacks just make it too easy to implement the former solution.

Also, keep in mind that you still have to wrap try...except blocks around all your yield calls, as they're the only way to trap errbacks within your code (unless a calling function of an inlineCallbacks function handles the errback at that level).

So, I find it's not really a question of performance per se, but rather good habits that would make me recommend against inlineCallbacks in general - they're still great for quick code snippets, multi-stage initialization routines, or tests for example.