Bug 119888 – [GTK] WKTR spends irrational amount of time loading about:blank in g_list_length

• Component: WebKitGTK
• Status: NEW

[Zan Dobersek]

With fontconfig initialization disabled, loading about:blank in WKTR spends most of the time in g_list_length

[Zan Dobersek]

Created attachment 208904 [details]
Top 50 profiled symbols

This file shows the top 50 time-consuming points of code execution when loading about:blank under WKTR with FontConfig initialization (font loading etc.) disabled.

[Zan Dobersek]

Turns out that with a large enough libsoup cache, the soup_cache_load method takes quite some time to execute - roughly 10% of the whole time is spent in either g_variant_iter_loop or in g_list_length that's called by soup_cache_entry_insert in soup_cache_load.

While I'm profiling this through WKTR, I can imagine this also applies to MiniBrowser, Epiphany etc, so this should be optimized somehow. Maybe load the Soup cache asynchronously, if that's viable? Or further optimize the method?

https://git.gnome.org/browse/libsoup/tree/libsoup/soup-cache.c#n1494

[Zan Dobersek]

Created attachment 208956 [details]
Call graphs for g_list_length, g_variant_type_info_check

The call graphs for both g_list_length and g_variant_type_info_check.

[Martin Robinson]

(In reply to comment #3)
> Created an attachment (id=208956) [details]
> Call graphs for g_list_length, g_variant_type_info_check
> 
> The call graphs for both g_list_length and g_variant_type_info_check.

I wonder if it also makes sense to disable the disk cache for layout tests. Hopefully libsoup isn't actually caching file URLs.

[Sergio Villar Senin]

(In reply to comment #2)
> Turns out that with a large enough libsoup cache, the soup_cache_load method takes quite some time to execute - roughly 10% of the whole time is spent in either g_variant_iter_loop or in g_list_length that's called by soup_cache_entry_insert in soup_cache_load.
> 
> While I'm profiling this through WKTR, I can imagine this also applies to MiniBrowser, Epiphany etc, so this should be optimized somehow. Maybe load the Soup cache asynchronously, if that's viable? Or further optimize the method?
> 

Yes it's a known issue. There are a couple of bugs in libsoup where I started some fixes for that. The main issue is that we load all the HTTP headers when loading the cache. There are different approaches to fix that, but I never found enough time to completelly implement them.