After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 687662 - searching for applications blocks the compositor thread
searching for applications blocks the compositor thread
Status: RESOLVED OBSOLETE
Product: gnome-shell
Classification: Core
Component: search
3.6.x
Other Linux
: Normal normal
: ---
Assigned To: gnome-shell-maint
gnome-shell-maint
Depends on:
Blocks: 687362
 
 
Reported: 2012-11-05 16:08 UTC by Simon McVittie
Modified: 2021-07-05 14:39 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
strace log (190.99 KB, text/plain)
2012-11-05 16:19 UTC, Simon McVittie
Details
sysprof corresponding to Attachment #228147 (70.24 KB, application/octet-stream)
2012-11-05 16:21 UTC, Simon McVittie
Details

Description Simon McVittie 2012-11-05 16:08:27 UTC
+++ This bug was initially created as a clone of Bug #687362 +++

* Log in
* Let the screen lock, and unlock it (as per Bug #687460)
* Open the overview (as per Bug #687364)
* Open the applications view (as per Bug #687661)
* Close and reopen the overview
* Start profiling/logging
* Press "p", which on my test laptop matches several applications and capplets (below)
* Stop profiling/logging

Applications displayed: Totem, Pidgin, System Settings, Shotwell, pyBootchartGUI, Power Statistics, Startup Applications

Capplets displayed on my test laptop: Printers, User Accounts, Details, Network, Colour, Power, Mouse & Touchpad
Comment 1 Simon McVittie 2012-11-05 16:19:02 UTC
Created attachment 228147 [details]
strace log

Some highlights:

Lines 76-399 block for 867ms, including stat()ing icon theme directories, followed by 39ms without I/O, followed by starting thread 4026 to load edit-clear-symbolic.svg.

There seems to be a fair amount of futex contention between the main thread, the image-loader thread 4026, and the GDBus thread during lines 530-833, perhaps contributing to the main thread blocking for 246ms during that period.
Comment 2 Simon McVittie 2012-11-05 16:21:43 UTC
Created attachment 228149 [details]
sysprof corresponding to Attachment #228147 [details]

Profiling for Attachment #228147 [details].

Highlights include:

4.46% add_matched_properties
3.47% g_hash_table_lookup
2.48% additional_selector_matches_style
2.48% g_type_check_instance_is_a
2.48% js::Interpret
1.98% string_in_list
1.49% clutter_actor_get_type
1.49% st_theme_node_get_type
Comment 3 Simon McVittie 2012-12-06 14:24:03 UTC
(In reply to comment #2)
> 4.46% add_matched_properties
...
> 2.48% additional_selector_matches_style
...
> 1.98% string_in_list
...
> 1.49% clutter_actor_get_type
> 1.49% st_theme_node_get_type

These were probably cut significantly by Bug #687465, if someone wants to re-profile. (I'm no longer actively working on Shell performance, but I might return to it at some point.)
Comment 4 GNOME Infrastructure Team 2021-07-05 14:39:45 UTC
GNOME is going to shut down bugzilla.gnome.org in favor of  gitlab.gnome.org.
As part of that, we are mass-closing older open tickets in bugzilla.gnome.org
which have not seen updates for a longer time (resources are unfortunately
quite limited so not every ticket can get handled).

If you can still reproduce the situation described in this ticket in a recent
and supported software version, then please follow
  https://wiki.gnome.org/GettingInTouch/BugReportingGuidelines
and create a new ticket at
  https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/

Thank you for your understanding and your help.