Profiling Rocks - KDevelop CMake Support now 20x faster
I just need to get this out quickly:
We were aware that KDevelop’s CMake support was slow. Too slow actually. It was profiled months ago and after a quick look that turned up QRegExp, it was discarded in fear of having to rewrite the whole parser properly, without using QRegExp. Which btw. is still a good idea of course.
But well, today I felt like I should do some more tinkering. I mean I managed to optimize KDevelop’s Cpp support recently (parsing Boost’s huge generated template headers, like e.g.
vector200.hpp is now 30% faster). I managed to make KGraphViewer usable for huge callgraphs I produce in Massif Visualizer. So how hard could it be to make KDevelop’s CMake at least /a bit/ faster, he?
Yeah well an hour later and two commits later, I managed to find and fix two bottlenecks. Both where related to QRegExp. Neither was the actual parser, instead it was the part that evaluated CMake files, esp. the
STRING(...) function. So even if we’d used a proper parser generator, this would still been slow.
The first one was the typical “don’t reinvent the wheel” kinda commit which already made the CMake support two times faster for projects that used
FindQt4.cmake, i.e. any Qt or KDE project. Not bad, right? Well, while I fixed that I saw that KDevelop tried to do some Regular expression replacement on the output of
qmake --help, this could not been right, could it? With help of Andreas and Aleix we found the bug in the parser and that made the CMake support 10 times faster.
So yeah, CMake projects using Qt or KDE should now get opened a whopping 20 times faster in KDevelop :)
I really love KCacheGrind and Valgrind’s callgrind - again it proved to be the most awesome tool one can imagine! If you are interested in the callgrind files:
- without optimization
- first optimization
- second optimization
Note: with KCacheGrind from trunk you can open these compressed files transparently :)