Silly CMake 2.8.2 regex causing slow project load in KDevelop

Andreas Pakulat apaku at
Mon Jul 19 21:16:46 UTC 2010

On 18.07.10 23:35:36, Nicolás Alvarez wrote:
> Since I upgraded to CMake 2.8.2, KDevelop takes almost four minutes to
> load my project, before it appears in the Project toolview and C++
> parsing starts. I tracked it down to a very slow regex in
> FindZLIB.cmake:
> \"([0-9]+)\\.([0-9]+)\\.([0-9]+)\".*" "\\1.\\2.\\3"
> On my machine, and with my zlib.h, QRegExp takes 3 minutes 55 seconds
> to process the regex (measured, test case attached), while CMake takes
> 10 seconds (still unacceptable imho). The regex doesn't even work on
> my version of zlib.h (because ZLIB_VERSION has four version
> components, ""). Looks like the fact that it doesn't match is
> what *makes* it slow; I edited zlib.h to have three version components
> ("1.2.3") and both cmake and kdevelop take a fraction of a second.
> There is a CMake bug reported about this:
> Note that FindZLIB.cmake is *not* checking cache variables before
> running the regex, so it always runs. This means that if I modify a
> CMake script in my zlib-using project, the project is reloaded, and it
> disappears from the Project toolview for another four minutes(!).
> Is there anything we could do in KDevelop to work around the stupidity
> in this CMake release? :) At the moment my only ideas are:

Seems you have a pretty fast machine, my new desktop machine took
11minutes to chew through the regex-stuff. 

So my updated measurements are that it takes the same time (almost none)
with just 3 digits, but with 4 its 11minutes. And release vs. debug
doesn't make a real difference there.

IMHO this should be reported as bug to Nokia too, its not acceptable
that QRegExp needs 11 minutes to match this regex against such a small
file (grep is instant after removing all \n from the file).


Your business will go through a period of considerable expansion.

More information about the KDevelop-devel mailing list