Xpra: Ticket #225: calculate batch delay is expensive and hurts performance
Using profiling during #224, I found that we call calculate_batch_delay
far too often and that it is way too expensive. (see callgraph attached)
We now avoid calling it when we are pretty sure it won't help, see r2291:
self._damage(window, 0, 0, w, h, options={"calculate" : False, "min_delay" : 50})
What we still need to do:
- don't call this from the UI thread: either have a dedicated thread (running at low priority with long pauses, or even wake up events fired from the other threads when they think the delay needs updating) or call it from the damage thread.
- run most of it from
ServerSource
, and call each WindowSource
with the partial results so window-specific values can be applied without re-calculating all of it for each window.
- keep an overall batch delay in
ServerSource
so that any new window can inherit a good guess of what the delay should be initially, without needing to calculate anything.
- maybe re-write some of it in cython to improve performance
Fri, 21 Dec 2012 04:23:48 GMT - Antoine Martin: attachment set
- attachment
set to pycallgraph-damage2.png
shows where the time is being spent when dealing with damage requests in UI thread
Fri, 21 Dec 2012 04:25:15 GMT - Antoine Martin: status, description changed
- status
changed from new to accepted
- description
modified (diff)
Tue, 08 Jan 2013 15:12:47 GMT - Antoine Martin: status changed; resolution set
- status
changed from accepted to closed
- resolution
set to fixed
- r2424 and r2425 moved the calculations to a separate thread and refactored them to ensure we only calculate common values once
- r2461 ensure we calculate the target latency in that thread as it is quite an expensive calculation (at least too expensive to do in the critical damage path)
- r2462 allows to use a cython variant for the calculations, giving another huge speedup
This is now mostly solved, although there may be further optimizations we can make.
Sat, 23 Jan 2021 04:48:55 GMT - migration script:
this ticket has been moved to: https://github.com/Xpra-org/xpra/issues/225