xpra icon
Bug tracker and wiki

This bug tracker and wiki are being discontinued
please use https://github.com/Xpra-org/xpra instead.

Opened 9 years ago

Last modified 9 months ago

#225 closed defect

calculate batch delay is expensive and hurts performance — at Version 1

Reported by: Antoine Martin Owned by: Antoine Martin
Priority: major Milestone: 0.9
Component: server Version: trunk
Keywords: Cc:

Description (last modified by Antoine Martin)

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

Change History (2)

Changed 9 years ago by Antoine Martin

Attachment: pycallgraph-damage2.png added

shows where the time is being spent when dealing with damage requests in UI thread

comment:1 Changed 9 years ago by Antoine Martin

Description: modified (diff)
Status: newaccepted
Note: See TracTickets for help on using tickets.