xpra icon
Bug tracker and wiki

Opened 6 months ago

Closed 4 weeks ago

#2219 closed task (fixed)

compare performance of gtk2 and gtk3 builds

Reported by: Antoine Martin Owned by: Antoine Martin
Priority: major Milestone: 3.0
Component: core Version: 2.4.x
Keywords: Cc:

Description

In light of ticket:2211#comment:4 : Is GTK3 that much slower?

We need some hard numbers.
Let's run the full automated tests and compare.

Attachments (1)

test_gtk.tar.gz (176.6 KB) - added by Smo 4 weeks ago.
comparison of gtk2 and gtk3

Download all attachments as: .zip

Change History (4)

comment:1 Changed 7 weeks ago by Antoine Martin

Owner: changed from Jonathan Anthony to Smo
Status: assignednew

Changed 4 weeks ago by Smo

Attachment: test_gtk.tar.gz added

comparison of gtk2 and gtk3

comment:2 Changed 4 weeks ago by Smo

Owner: changed from Smo to Antoine Martin

I've attached some logs, data, and charts. I did this test by changing the top of

/usr/bin/xpra to be python3 instead of python2 to force make it try python3 first

I still have an issue with gtkperf the data looks all wrong and when I watch it running it appears to be going through the tests super fast so i'm not sure what is going on there.

Will just omit that one for now and try and see what the issue with it is.

Still some nice data here.

comment:3 Changed 4 weeks ago by Antoine Martin

Resolution: fixed
Status: newclosed

... /usr/bin/xpra to be python3 instead of python2 to force make it try python3 first

FYI: that should already be the case when installing from RPM.

Very nice!
I have uploaded the charts here: https://xpra.org/stats/gtk2-vs-gtk3/charts.html.

Overall, this is an unexpected decisive win for GTK3 in most key metrics:

  • lower batch delay - except for x11perf
  • lower damage latency - except for glxgears
  • higher quality - except for glxgears
  • much lower max batch delay and max damage latency, even memscroller is almost where it should be
  • higher quality and more pixels-per-second sent
  • more regions-per-second
  • less server CPU! despite compressing and sending more data

The only metrics which are showing regressions are:

  • 15% more memory usage on the server, 25% more on the client
  • the user CPU is a bit higher, but that is mostly in line with the increased number of pixels that are processed (thanks to the better framerate)
  • the encoding and decoding "pixels-per-second" - not too critical, but I will try to look into this as there is quite a big gap, maybe because:

It looks to me like gtk3 is using video encodings more aggressively: more threads, more cpu, etc. Not sure why that is.

Note: See TracTickets for help on using tickets.