to yield or not to yield

[Antoine Martin]

r1365 introduced the XPRA_YIELD environment variable to toggle thread yielding in both network threads (protocol.py) and encoding thread (server_source.py).

Which means we now have graphs comparing with/without yield (also split between each type of yield) here:
​https://www.xpra.org/stats/YIELD-vs-NOYIELD/

Notes:

• each page has two sets of graphs: there is no download limit in the top half and (128-KB/s-down, 32-KB/s-up, 100ms-latency) in the bottom half
• gtkperf is problematic throughout.. (beware when looking at specific graphs: in some cases it performed very badly, which means other measures like latency will actually look good!)
• deluxe and polytopes benefit a lot from yielding with download limits
• the client latency has some conflicting results, 'eruption' is much worse with yielding but most other tests are either unchanged or much improved ('polytopes', 'rss-glx*')
• the number of packets sent is the same or higher when yielding
• we manage to send more pixels/s, although it seems that in a number of cases only one type of yielding is beneficial and having both negates the gains (and in a few cases, actually perform worse!)
• apart from 'polytopes' and 'eruption', when it comes to regions/s, the yielding in the network code is the big winner

And so, the conclusion is... to leave it as it is for now and run more tests once a few other performance/latency issues are resolved.

[Antoine Martin]

Review with 0.7 release:

• we have more threads on the client with the new decoding thread, maybe we need to yield more?
• latency is now much better - maybe this will have more/less of an impact?

[Antoine Martin]

We may revisit things later, but this seems to work ok for now.

[migration script]

this ticket has been moved to: ​https://github.com/Xpra-org/xpra/issues/181