Results of the second batch of Sysprof shenanigans
I've been running another profiling session with Sysprof, and now that icon downloads are out of the equation, I thought we might benefit from fresh new data. I've applied the following diff to GNOME Software's Flatpak plugin:
Diff: More Profiling
diff --git a/plugins/flatpak/gs-flatpak.c b/plugins/flatpak/gs-flatpak.c
index f8306e50c..d169c8961 100644
--- a/plugins/flatpak/gs-flatpak.c
+++ b/plugins/flatpak/gs-flatpak.c
@@ -3434,22 +3434,30 @@ gs_flatpak_refine_app_unlocked (GsFlatpak *self,
if (!ensure_flatpak_silo_with_locker (self, locker, interactive, cancellable, error))
return FALSE;
+
+ GS_PROFILER_BEGIN_SCOPED (FlatpakRefineAppRefineAppstream, "Flatpak (app; refine AppStream)", NULL);
/* always do AppStream properties */
if (!gs_flatpak_refine_appstream (self, app, self->silo, flags, interactive, cancellable, error))
return FALSE;
+ GS_PROFILER_END_SCOPED (FlatpakRefineWildcardCreateAppstreamApp);
+ GS_PROFILER_BEGIN_SCOPED (FlatpakRefineAppRefineItemMetadata, "Flatpak (app; refine item metadata)", NULL);
/* AppStream sets the source to appname/arch/branch */
if (!gs_refine_item_metadata (self, app, error)) {
g_prefix_error (error, "failed to get metadata: ");
return FALSE;
}
+ GS_PROFILER_END_SCOPED (FlatpakRefineAppRefineItemMetadata);
+ GS_PROFILER_BEGIN_SCOPED (FlatpakRefineAppRefineAppState, "Flatpak (app; refine app state)", NULL);
/* check the installed state */
if (!gs_flatpak_refine_app_state_unlocked (self, app, interactive, cancellable, error)) {
g_prefix_error (error, "failed to get state: ");
return FALSE;
}
+ GS_PROFILER_END_SCOPED (FlatpakRefineAppRefineAppState);
+ GS_PROFILER_BEGIN_SCOPED (FlatpakRefineAppRefineTheRest, "Flatpak (app; refine the rest)", NULL);
/* hide any addons that aren't for this app */
if (!gs_flatpak_prune_addons_list (self, app, interactive, cancellable, &local_error)) {
g_warning ("failed to prune addons: %s", local_error->message);
@@ -3546,6 +3554,7 @@ gs_flatpak_refine_app_unlocked (GsFlatpak *self,
gs_flatpak_set_app_origin (self, app, gs_app_get_origin (app), NULL, interactive, cancellable);
return TRUE;
+ GS_PROFILER_END_SCOPED (FlatpakRefineAppRefineTheRest);
}
void
My test routine was:
- Kill GNOME Software
- Run GNOME Software using Sysprof
- Open each one of the 6 categories
First, this is how it generally looks here:
You can see 7 "blocks" in the gnome-software
row; the first block is the initial loading of the application, the rest are the categories. Seems like most of the CPU time is spent on libxmlb.
If we take a look at the statistics page, we have the following:
These marks suggest that in our case, what's consuming most of the time is the massive number of tiny Flatpak (refine wildcard)
operations that happen. On average they take ~3ms but we do hundreds of them for each category that we want to browse, the numbers explode.
Seems like the initial mapping / loading of libxmlb files is also taking a considerable amount of time, but it seems to happen only once in a while, so it doesn't impact too much, all things considered.