Hi, > >>> 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. I tested it my small test program, which simply stores 1000 ramdom number as strings into trie. The benchmarks are: Original: 5-8 seconds (seems to depend a lot on actually generated numbers) libdatrie version: 0.002 seconds Your patch: 0.01 second The result is more than evident: the difference between current implementation and other two is extreme. The difference between libdatrie and your patch is meaningless by human standarts. I'll try to improve my test app to generate something more like text, but I don't expect something alike the numbers above. Since my version with libdatrie is incomplete and adds additional dependency (which I prefer to make optional), I see little point to continue working on it, while your patch should be applied anyway. Well done! -- Aurimas
Attachment:
signature.asc
Description: This is a digitally signed message part