GNOME Bugzilla – Bug 765284
debug: reduce runtime overhead in debug builds
Last modified: 2016-04-20 03:43:24 UTC
This only affects debug builds, but we do spend a lot of the cycle running debug builds. So speeding this up makes it easier to focus on other things that change runtime performance. The g_object_get_data() combined with the quark lookup (and associated bit locks) was accounting for about 7% of the collected callchains when sampling GtkSourceView performance. With this patch we are down to less than .5%. That is a much more acceptable overhead for debug runtime checks. Additionally, we remove the open-coded debug checks in gtktextsegment in favor of our compile-time conditional debug check macro.
Created attachment 326364 [details] [review] debug: avoid GQuark and GData usage in gtk_get_debug_flags() This only affects debug builds, but we do spend a lot of the cycle running debug builds. So speeding this up makes it easier to focus on other things that change runtime performance. The g_object_get_data() combined with the quark lookup (and associated bit locks) was accounting for about 7% of the collected callchains when sampling GtkSourceView performance. With this patch we are down to less than .5%. That is a much more acceptable overhead for debug runtime checks.
Created attachment 326365 [details] [review] debug: remove open-coded debug checks in gtktextsegment These runtime checks were being performed whether or not we were in a debug build. Using GTK_DEBUG_CHECK() will compile out of production builds, as it will result in something like: if (G_UNLIKELY(0)) which the optimizer can prune.
I appreciate the performance win, but storing gtk debug flags in gdk structures seems wrong to me.
Review of attachment 326365 [details] [review]: this looks fine to me
(In reply to Matthias Clasen from comment #3) > I appreciate the performance win, but storing gtk debug flags in gdk > structures seems wrong to me. I had the same feeling, but having debug flags per-display seemed a bit strange too. I take it that is something we use the inspector for? Any other ideas for where to stash it?
We want to avoid visual debugging flags affecting the inspector, which is why we scope them to the display (the inspector has its own display connection). I've pushed a few fixes to reduce the cost a bit.
Seems good enough. It gets things down to about ~3% due to the type check.