Re: [gtkmm] Custom TreeStore Problems

[Christof Petig <christof petig-baender de>]

Murray Cumming Comneon com schrieb:
> I suspect that Kristian Rietvel (kris) would be worth talking to on irc
> about treeview performance. I don't want to believe that a custom treemodel
> is necessary. 

Well I suspect that the problem _might_ be in the overhead of the C++ 
wrapping.

What I did was:
- sorted insertion of 10000 lines into a TreeStore (actually it becomes 
a subtree whenever columns match)
  the sort criterion was a custom class defining operator<
  key and additional data were referenced by smart pointers (handles)

I used std::upper_bound/std::equal_range on the TreeStore to find a 
suitable position.

What I found by profiling:
- many many many refs and unrefs of my key/value type (remember 
TreeModelColumn< Handle <some data> > )
- many many many TreeStore::iterator++
- Once I statically compiled gtkmm and gtk for profiling I found 4 
seconds out of 20 spent in (application,gtkmm,gtk).
- I never found a library (LD_PROFILE,sprof) in which the time was spent 
(neither was it in my program)
- I finally gave up and tried a custom tree model (based on 
std::multimap) => about 2 seconds for 10k rows, all inclusive

Possible problems might be:
- random access (by index) into a tree like structure (iterator 
conversion) or vice versa [internal mismatch of iterator concepts]
[Problem might lie between gtkmm/gtk/glib]
Because of the binary search (in topmost abstraction level) this will 
get worse. I found that TreeModel defines n-th child access methods but 
a tree (IIRC TreeStore uses a glib based tree) can't do that efficiently.

- losses due to end() emulation [Of course I need to call end() at least 
N*logN times and there are a lot of comparisons]

- losses due to frequent GValue and Handle<> conversion/ passing/ 
duplication [perhaps the boxed type implementation does not scale that well]

Since other people (*) have also found "for() { iter=append(); 
(*iter)[]=... }" to be slow I suspect that gtkmm has a somewhat 
inefficient (though wonderfully type-safe designed) use of GtkTreeModel.

My current needs are surpassed by my std::multimap<->Gtk::TreeModel 
adaptor (*2).
   Christof

*) http://mail.gnome.org/archives/gtk-list/2003-March/msg00361.html
*2) 
http://cvs.berlios.de/cgi-bin/viewcvs.cgi/*checkout*/manuproc/Komponenten/Basic/src/?only_with_tag=CUSTOM_TREEMODEL
(part of a bigger framework)