>>> https://bugzilla.gnome.org/660663 >> >> This patch should improve performance, the question is how much. >> When I tried to profile Gnote with a lot of notes, it looked like Trie >> is the major factor for performance. Each time note is >> added/removed/renamed, the Trie structure gets rebuilt from scratch. I >> have experimented a bit with libdatrie >> (http://linux.thai.net/~thep/datrie/datrie.html), which has way better >> performance, so I think of using it for our Trie. > > I have explained how I created the set of notes for checking the > performance. I do not know whether Gnote's behaviour with that set matches a > real life scenario or not. > > Having said that, with 3000 randomly named notes, the new trie is no longer a > problem. There is a significant delay caused by something else, and that > happens to be this Gtk::ListStore code. You can check this by adding the two > patches (first the trie, then this one) and then put std::cout's before and > after the calls to the trie in src/notemanager.cpp. The delay is in the order > of 5 - 10 sec on my 4 year old Core 2 Duo Macbook. Oops! If you apply the second patch, that is https://bugzilla.gnome.org/660663, then obviously you will not see this delay any more. :-) So to see the delay caused by the non-trie code, just apply the new trie patch, and then check. Sorry for the confusion. Happy hacking, Debarshi
Attachment:
pgp7LxvveuoN4.pgp
Description: PGP signature