GNOME Bugzilla – Bug 430095
Improving the performance of GtkTreeView by reducing the number of unnecessary walking of lists
Last modified: 2018-04-15 00:38:45 UTC
Recently there was discussion on gtk-devel-list about GtkTreeView performance (starting from here: http://mail.gnome.org/archives/gtk-devel-list/2007-March/msg00231.html). It was pointed out that there are several places where lists are used needlessly. * Keeping column types in linked list is a waste, but an array would do much better. * Sort function is looked up by walking a list before each compare function call, even though this information could be cached while changing the sort column. This bug is opened in order to organize the patches related to this matter.
Created attachment 86395 [details] [review] Patch to reduce unneeded usage of lists in treemodels This is otherwise the same patch that I sent to gtk-devel-list earlier, but it also contains a version of caching GtkTreeDataSortHeader.
Something is not quite right with the patch: testtreeview segfaults, with the following stacktrace: Program received signal SIGSEGV, Segmentation fault.
+ Trace 130631
Thread NaN (LWP 20370)
Created attachment 87096 [details] [review] Modified patch that fixes a NULL pointer reference Yeah, my bad :( I didn't detect that _gtk_tree_data_list_free was actually called with NULL argument. Now testtreeview runs nicely.
Hmm, testtreeview is fixed, but testtreemodel still segfaults here:
+ Trace 130965
Also there are some minor indentation and whitespace issues in the patch, like missing spaces before '('.
The changed function signature of my _gtk_tree_data_list_free caused this one. I needed to introduce a helper function to use with g_sequence_foreach. I'll go trough the patch for formatting changes...
Created attachment 98911 [details] [review] Updated the patch * Fixed the crash when finalizing a GtkListStore (wrong function signature). * Implemented sort_header caching for GtkTreeStore. I changed unused "last" member from GtkTreeStore structure to hold this information. Nobody was using it currently and it should be treated as private data. I wonder if a change like this is a problem? * Reviewed the coding style
still a potentially valid (micro-)optimization
We're moving to gitlab! As part of this move, we are moving bugs to NEEDINFO if they haven't seen activity in more than a year. If this issue is still important to you and still relevant with GTK+ 3.22 or master, please reopen it and we will migrate it to gitlab.
As announced a while ago, we are migrating to gitlab, and bugs that haven't seen activity in the last year or so will be not be migrated, but closed out in bugzilla. If this bug is still relevant to you, you can open a new issue describing the symptoms and how to reproduce it with gtk 3.22.x or master in gitlab: https://gitlab.gnome.org/GNOME/gtk/issues/new