GNOME Bugzilla – Bug 680059
[PATCH] Copy-on-write sharing for GtkWidgetPath elements
Last modified: 2012-07-31 23:15:03 UTC
Created attachment 218954 [details] [review] Use copy-on-write sharing Hi, using GTK+ 3.4.3 here. While profiling the startup time of Audacious, I found that malloc() was being called an excessive number of times inside gtk_path_element_copy(). In fact, gtk_path_element_copy() was called called no less than 46,000 times during startup. Now, gtk_path_element_copy() performs a full copy of a GArray and a GHashTable, so it is a fairly expensive function to be calling 46,000 times. Furthermore, most (over 90 percent) of the 46,000 GtkPathElement objects created are identical copies that are never modified. By adding a reference count to each GtkPathElement, with copy-on-write sharing, I reduced the number of GtkPathElement objects to 3,200. Please consider applying the attached patch, as it should result in a significant saving of both memory and CPU time for many GTK+ programs. Note that the patch applies after my previous patch in #679978.
Nice idea. Alex talked with me about doing something like this pre-3.4 but didn't get around to it. In git master / GTK 3.6 this whole approach has changed however, and we now don't store the widget path at all, but instead allocate widget paths whenever we need them and then discard them again. So the memory use should be even less. I have no idea how this patchset would change the performance characteristics of the current codebase, so I'm not gonna comment on the CPU time until someone has measured things. I'd be very interested in comparisons of your approach with the current master branch though. As a side note: I wouldn't want to apply such a patch to GTK 3.4 though because I'd be too afraid to introduce bugs to stable shipping software.
Hi Benjamin, Thanks for your response. I'll take a look at the Git code. I wouldn't expect this to be merged into 3.4.x anyway.
I benchmarked Audacious startup time and RSS size with various GTK+ versions: 3.4.4 before patching: 15944 KB, 166.2 million CPU cycles 3.4.4 after patching: 13440 KB, 155.1 million CPU cycles 3.5.8 before patching: 15848 KB, 202.2 million CPU cycles 3.5.8 after patching: 15860 KB, 202.9 million CPU cycles So, at first glance, it looks like this patch no longer brings about any improvement in GTK+ 3.5.x (in fact, it ever so slightly increases both memory use and startup time). But at the same time, GTK+ 3.5.x is not significantly better than unpatched 3.4.x with regard to memory usage, and is much worse in regard to startup time. I will try to take a closer look at what is going on; perhaps there are other improvements that can be made in 3.5.x.
Most of the extra weight of 3.5.x seems to be caused by the new ATK stuff. At any rate, I think the GtkWidgetPath problem is resolved, so this report can be closed.
Hrm, in theory atk should not cause any extra weight if accessibility is not enabled. But you should be able to achieve the same result in 3.4 by setting the env var GTK_MODULES=atk-bridge
John: Anything more to be done here? Seems 3.5.8 is ok right?
Yep, 3.5.8 seems to be good.
The let's close this as, hrm, nah, OBSOLETE sounds so bad.