[prev in list] [next in list] [prev in thread] [next in thread] 

List:       gtk-devel
Subject:    Re: Does GTK+ do automated/nightly performance regression testing?
From:       Emmanuele Bassi <ebassi () gmail ! com>
Date:       2018-02-05 10:49:50
Message-ID: CALnHYQECiWhp+rjOkzp198VtTKpaO-D3RL4U4qy7g0QN0vfJ8Q () mail ! gmail ! com
[Download RAW message or body]

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
>> work?
>
> 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
> that.

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
pipeline.

I've recently done some work in that regard, with nearly-zero cost
profile probes for the Endless SDK:
https://github.com/endlessm/eos-sdk/blob/master/endless/eosprofile.c#L18

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.

Ciao,
 Emmanuele.
-- 
https://www.bassi.io
[@] ebassi [@gmail.com]
_______________________________________________
gtk-devel-list mailing list
gtk-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-devel-list

[prev in list] [next in list] [prev in thread] [next in thread]