[Twisted-Python] Why deferToThread is so slow?

[Glyph]

> On Jun 3, 2016, at 01:06, Nagy, Attila <bra at fsn.hu> wrote:
> 
> Hi,
> 
> I have a thread safe synchronous library, which I would like to use in a threadpool using deferToThread.
> 
> Without using (deferTo)threads I get consistent 1-3 ms response times, with deferring to threadpool, I get 30-300, varying wildly.

Why do you think this is bad performance?

With a direct call, you are doing almost nothing.  Just pushing a stack frame.

With a deferToThread call, you are:

acquiring the GIL,
pushing a message into a call queue,
releasing the GIL,
waiting for the worker thread to wake up,
acquiring the GIL,
pulling the work off the queue,
invoking the work in the worker thread,
storing the response on a return queue,
writing a byte into a pipe to wake up the reactor thread,
releasing the GIL,
waiting for the reactor thread to wake up,
acquiring the GIL,
reading the byte from the pipe,
pulling the response work off the queue,
executing it,
then invoking a Deferred's callback chain.

Each of these steps involves a couple of function calls each, and if each takes 3ms like your simple no-op call, you're looking at 48ms just for starters, not taking into account the fact that when you start tossing things into pipes and mutexes the kernel's scheduler gets involved and may (as you noticed) introduce large amounts of non-determinism as other processes and threads run.

While I would certainly like to see this get faster, and I think it probably could be optimized somewhat, it's not reasonable to expect that a single function call could be competitive with this sort of algorithm, when it's made up of so many function calls of its own.

I could definitely be convinced that this is unreasonably slow but it does not seem so from a first reading.

-glyph

-------------- next part --------------
An HTML attachment was scrubbed...
URL: </pipermail/twisted-python/attachments/20160603/52b65832/attachment-0002.html>