Re: Does GTK+ do automated/nightly performance regression testing?

On 5 February 2018 at 10:40, Timm Bäder <mail baedert org> wrote:
On 05.02, Clemens Eisserer wrote:
So back to the original question: How does the GTK+ project make sure
to spot performance regressions when they are introduced?
And if there is nothing automated, would there be interest in such a
project -  Would it be useful and used by the developers doing feature

Aside from what Emmanuele already said: yes, that would be very useful.
However, the performance problems in gtk4 are not that much related to
rendering (mostly...), but the much bigger problem is CSS
(in)validations. GTK4 does a lot more CSS state changes due to automatic
focus and :hover tracking with CSS pseudo classes. While the number of
CSS nodes should not have significantly increased, the fact that we e.g.
set :hover on a listbox node with many children is new in gtk4. But then
again, this is already known to be slower and what we need is a fix for

Yep; this is also why comparing GTK 2/3 performance with GTK4 is
wildly misleading: GTK4 does *so much more* than GTK3 or GTK2 ever
did, and mostly does it to ensure that the toolkit behaves
consistently, instead of having behaviour depend on each class.

Still, I think even if you can't automate it, a performance testsuite
for certain things (or just a bunch of executables in tests/, really)
would be good in any case.

Indeed, and we should probably provide some internal feature to add
profiling probes to the toolkit itself, so we could expose them via
the inspector and via a CLI tool that could be used in the CI

I've recently done some work in that regard, with nearly-zero cost
profile probes for the Endless SDK:

GSK has a prototype of a profiling object that should be improved;
Christian Hergert has worked on performance counters for sysprof and
gnome-builder, so we should also look at that.

[@] ebassi []

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]