GNOME Bugzilla – Bug 750634
after closing gnome-software application stays running in the background, but doesn't release "~any" memory
Last modified: 2017-02-17 11:50:46 UTC
gnome-software start-up with the system in the background even if shell search provider function is disabled from settings (I asked on IRC, "you" (devs) said it is for updates checking (which is OK)). When system starts up gnome-software on my system uses ~0.6% of RAM (of 4GB) ~5MB or RAM used, this is OK. The problem is when user starts gnome-software and closes it later, in my case when GUI is started/shown gnome-software uses ~2.6% of RAM ~70MB, which is also OK for a running application, but if I close the application, window disappears, gnome-software is still running in the background and uses probably the same amount of RAM as when it was running in the foreground (~2.6% / ~70MB). It would be nice if gnome-software can release unneeded memory when it goes to background mode again. gnome-software-3.16.2-2.fc22.x86_64
I pushed two fixes that should make this a little bit better, but only if you have gsettings org.gnome.software download-updates set to false. In that case, gnome-software autostarts when needed (for PK session service requests over dbus, shell search provider queries, etc), but shuts down again after 12s. https://git.gnome.org/browse/gnome-software/commit/?id=046ba20bf9de4b2a050e15e877429f90fd24c7c7 https://git.gnome.org/browse/gnome-software/commit/?id=feba7e5a79edacbd80dde3561b79fcd61cbd6509
Some hints about "who else holds an app ref and prevents it from being freed": - a list of installed applications, - a list of featured and recommended applications, - the Details page. By "a list" I mean a list widget or a set of widgets, not a GList. One may consider freeing these widgets when all the g-s windows are closed.
I don't think it's the widgets/icons taking the majority of the RSS, It'll be the exploded AppStream data. There's not much we can do there as it takes 180ms to parse and we need to return results faster than that. I'd be interested to see any massif-style graphs of where the RAM is actually going.
I didn't mean the widgets themselves but I mean that the widgets hold a reference to GsApp and therefore it can't be freed. It's not a surprise that GsApp in turn holds exploded AppStream data. The GsApps and AppStream data could be freed if the main window was destroyed rather than hidden. Here is a place where it is hidden when the user presses the [X] button: https://git.gnome.org/browse/gnome-software/tree/src/gs-shell.c#n501 and here it is hidden when the user selects app menu → Quit: https://git.gnome.org/browse/gnome-software/tree/src/gs-application.c#n488 It's fixable but probably not as trivial as replacing gtk_widget_hide() with gtk_widget_destroy(). This is also related with bug 759038.
I've been profiling this. We can save just 10.7% by evicting loaded icons on "close". The majority of the 80Mb peak (for me) is in the AppStream metadata of which 85.6% needs to be kept in hot cache for searching. We could shave off 8% of that by pre-filtering the locale when loading, although there is no big easy saving I'm afraid.
So the question is: what can we do to be able to free all AppStream metadata? Can we free them after we free all GsApp instances plus maybe some period of inactivity? I think that after closing the main window g-s should eventually return to the state it had before opening the first window.
Okay, with the recent round of memory profiling in appstream-glib, in Fedora 25 there should be a good 40Mb less being kept in RSS. I think that's fine for now.