Big Speedup

October 2, 2008 at 9:32 pm | Posted in KDE, KDevelop | 8 Comments

First: Sorry David for spoiling, but I couldn’t keep my hands still after seeing this🙂

So, David Nolden, our DUChain and C++-Support Maintainer and Guru, comitted a couple of speed fixes today (including switching from QHash or stdext::hash_map to Google’s sparsehash). I thought, hmm, hopefully the parsing is a bit faster now, but in fact not only parsing. Almost everything is faster now, in particular the IMHO most annoying part: Highlighting in kate is a _lot_ faster now.

Recently I’ve mentioned this in a kde4-speed-rant-blog, when using cursor keys to scroll lines in kate only half of the window was updated until I stopped scrolling. This is gone now completely. Also plain typing feels a lot smoother now.

Another part that seems to benefit is “Quick Open”, all kinds – opening files, classes or methods are instantly opening up.

So a big thanks to David for this. KDevelop4 is really starting to take shape. Now the rest of us devs need to find more time to do their share🙂

8 Comments

  1. Hi!
    Only one question: will this be backported to KDE 4.1.x?

  2. Yay for David!!!!!!

  3. Of course this won’t be backported. KDE 4.1 doesn’t contain KDevelop, so there’s nothing that we can backport to🙂

  4. apaku: By “kate” you mean the kate part as used in KDevelop, not in the Kate editor, right? I wouldn’t mind if that one scrolled faster, too…

  5. @apaku: I think ziabice means a backport for kate.

  6. The editor component is the same in KDevelop and Kate-the-app. But David didn’t change any code there (though there are some speedup commits in trunk, IIRC). All the work has been done on the “Kdevelop side” of things.

    Hence there’s nothing to backport as katepart hasn’t been touched.

  7. Hmm, so that means that using QHash in such operations is not a good idea?

    I guess best would be if this was included in QHash so that all apps profit automatically and this would be possible, because sparsehash is released under BSD.

  8. It completely depends on your needs wether QHash fits the bill or not, remember premature optimization is the root of all evil. David spent a lot of time profiling the code and only changes from QHash->stdext::hash_map after the hash insertion/lookup showed up in the profile. Google’s dense_hash is only used in a few places now, where only little amount of data is stored.

    And IIRC he said the problem with QHash is related to its implicit sharing support, so I doubt you’ll convince TT to change the implementation to use Google’s dense_hash or sparse_hash. And for most use-cases QHash is probably fast and memory efficient enough, the needs of DUChain are pretty special here.


Sorry, the comment form is closed at this time.

Blog at WordPress.com.
Entries and comments feeds.

%d bloggers like this: