[Evolution-hackers] Why GtkTreeView sucks.

[Not Zed <notzed ximian com>]

Federico,

I just read your "blog" - you're wrong about how ETree works, or mistaken about what evolution mail uses (some things have changed since you last looked at it).  It only uses an ETreeModel, even for the flat view.  I'm not responding on the "blog" since I don't think that is very appropriate, or very polite.  I don't really want to get into an argument either, but I guess I have no choice.

I can tell you right now you don't need to waste your time profiling GtkTreeView, because the current design is fundamentally non-scalable and no amount of profiling will fix it.

ETreeSelectionModel subclasses ESelectionModel directly, it doesn't go anywhere near ESelectionModelArray.  When you ask for the selected rows, you get the result of a g_hash_table_foreach.  So first point, GtkTreeView's selection retrieval interface is O(N) on the number of rows, and ETree's is O(N) on the number of rows selected.  Obviously in almost any real application you're looking up the selected row(s) constantly, so its something which should be fast in the common case (i.e. 1 row selected).

Second, and this is also a factor that helps the selection model work at all, ETree doesn't use this GtkTreePath indirect reference-to-a-pointer crap (and it is crap).  The ETreePath's are pointers to the actual tree nodes used in the tree.  And dereferencing an ETreePath is O(1) (where 1 is close to 0), whereas it's O(N) for a GtkTreePath - depending on the tree implementation, and for most practical tree implementations it is O(N).  This means you don't need this GtkTreeReference stuff, since all Paths are already 'static' references.  Some of the performance issues from using GtkTreePath's for most uses (not the selection stuff) can be mitigated by vastly complicating your tree model, but that seems an expensive cost for something which doesn't add any value to start with anyway.

Basically GtkTreePath is the problem, the only reason ETreeSelectionModel can't have its own list/array/hashtable of selected items is that it would be forced to use a GtkTreeRowReference - which scale even worse, since GtkTreePath's are useless for static row references.

 Michael