GNOME Bugzilla – Bug 674719
Performance issues with gtk_tree_view_column_set_cell_data_func ()
Last modified: 2021-07-05 10:48:49 UTC
Created attachment 212691 [details] testcase It appears the the current gtk+ calls the function set via gtk_tree_view_column_set_cell_data_func () for each row where in the previous version it only did that for visible rows. This leads to poor performance in the "gtk_tree_view_set_model()" call for big models. I attach a demo testcase in pygi.
To add some numbers, running that on my 3.2 based version returns something like ~50 calls for get nr_cell_data_func_calls and in 3.4 more like ~20.000.
It seems like this is related to the users settings (a11y maybe?) and not the version. I.e. with current gtk+ I can not reproduce it in a guest session.
This is related to the caching behavior of atk-bridge. As such it only happens if an AT client (Orca or accerciser) is running. And for some reason atk-bridge seems to iterate all children of a treeview. I'm going to reassing this, the atk-bridge developers should have a better idea on how to avoid this.
There are several issues: at-spi2-atk is currently maintaining a cache, for the purpose of handling calls to GetItems, and updating this cache when seeing a children-changed signal. If it saw a children-changed::add signal with NULL passed in, as happens with tree views, then it would ref the accessible, which can still be somewhat expensive for treeview accessibles. It really shouldn't be caching transient objects like table cells anyhow, so I've made it ignore such signals in terms of the cache (commit f734be). This removes the main performance hit that we were taking when no AT was running. Appending to a tree view is still slow when an AT is running as a result of constructing and sending D-Bus signals. Some PropertyChange signals were being fired when it was unnecessary, so commit 67b25d should help some, but there are still events that get fired when children are added, their name is set, they become non-defunct, and text is added to them. There might be a way to filter out the object:state-changed:defunct events, since they are being sent to update the cache, but the table cells have STATE_TRANSIENT, so caching is not used for them anyhow. The other events are requested by Orca, and event registration is currently all-or-nothing (see https://bugzilla.gnome.org/show_bug.cgi?id=640440).
[Mass-resetting default assignee, see bug 705890. Please reclaim this bug report by setting the assignee to yourself if you still plan to work on this. Thanks!]
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/at-spi2-atk/-/issues/ Thank you for your understanding and your help.