Is uvloop relevant to trio?

[merrellb]

uvloop advertises some impressive gains in asyncio performance. However, I understand it is generally not considered compatible with other async libraries.

1. Are the gains substantial enough to make it an important consideration for other async libraries? Does the arrival of Pypy 3.5 beta mitigate this?

2. I understand mixing the asyncio and trio event loops is dangerous/not possible. However, could the asyncio event loop be exclusively leveraged (no interoperability) to run with trio if uvloop was worth the gains?

3. Any idea how much work it would be to actually port uvloop to trio? I imagine the original developer won't be interested until trio gets a bit more in popular :-)

[njsmith]

I haven't looked at uvloop in detail, but I did look at libuv fairly carefully, and AFAICT libuv is missing some features that trio needs. The main one is that most libuv operations don't support cancellation, but there are also some minor semantic mismatches like, iirc they don't have any way to call accept once, just a way to say "start accepting on this socket". (Maybe you can immediately tell it to stop from the first accept callback?) These issues reflect mismatches between the classic reactor API style like node and asyncio use, but trio doesn't. It's quite possible these can be handled (e.g., by submitting patches to libuv to support cancellation on more operations), but it would take some time and attention to work out.

Uvloop in particular also has the problem that because it's implemented as a C extension, it's probably considerably slower on pypy than CPython (if it works at all). The tradeoffs here are complicated and application specific, but certainly for many projects pypy will be more of a win than uvloop, if they have to choose. A cffi-based wrapper for libuv is probably a better starting point? (If someone wants to experiment then a cffi wrapper actually exists, though I haven't looked at it in any detail.) Also IIUC a lot of the magic in uvloop is careful optimization of asyncio-specific code, like a C implementation of their Future class, which wouldn't automatically carry over to trio anyway.

It's also likely that the low hanging fruit for optimizations is currently inside trio, not the actual io code. E.g. trio's decision to insist that all io primitives are checkpoints will definitely hurt it in throughput microbenchmarks; it's a trade-off I made intentionally to optimize for latency and correctness (it helps avoid cases where a fast client can starve out others). But it's also a place where the current implementation is stupid-simple and I know we can optimize away a lot of the added overhead with some cleverness :-). But that would need to be done in trio itself.

Have you seen the discussion of optimization in the design docs? An underlying problem here is that microbenchmarks like in the uvloop blog post can be super impressive, but are often a terrible guide to making anything better in the real world; they encourage a focus on trivialities and make it harder to make appropriate trade-offs. (Note that this isn't a criticism of uvloop in general – I'm pretty sure it was developed using real applications, and you have to communicate things somehow. And microbenchmarks definitely have a useful role to play. But when winning the microbenchmarks becomes your goal that I think that can really cause problems.) So ultimately I don't think there's much that can be said about trio's performance until we have some real apps to look at.

In the mean time do check out pypy if you're worried about performance, you might be surprised ;-)

[merrellb]

Thanks for the detailed response! It sounds like there are plenty of other things to focus on before digging into libuv and uvloop.

[njsmith]

Basically :-). If someone wants to experiment then I'll be super interested to see what they come up with, but there's no immediate concrete todo item and I'm not planning to work on this in the near future, so I'll close this for now. (Thanks for asking, though – I'm sure others with the same question will stumble across this in the future, so it's good to get written down!)