From kdevelop-devel  Mon Jul 19 07:10:37 2010
From: Andreas Pakulat <apaku () gmx ! de>
Date: Mon, 19 Jul 2010 07:10:37 +0000
To: kdevelop-devel
Subject: Re: Silly CMake 2.8.2 regex causing slow project load in KDevelop
Message-Id: <20100719071037.GA1225 () barmbek>
X-MARC-Message: https://marc.info/?l=kdevelop-devel&m=127952358122176

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:
> 
>    FILE(READ "${ZLIB_INCLUDE_DIR}/zlib.h" ZLIB_H)
>    STRING(REGEX REPLACE ".*#define ZLIB_VERSION
> \"([0-9]+)\\.([0-9]+)\\.([0-9]+)\".*" "\\1.\\2.\\3"
> ZLIB_VERSION_STRING "${ZLIB_H}")
> 
> 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, "1.2.3.4"). 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:
> http://www.itk.org/Bug/view.php?id=11005
> 
> 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:
> 
> - adding a workaround for this particular regex (a solution worthy of
> Microsoft :P yuuuuck!)

Not an option. We're also not adding workaround for Qt bugs most of the
time.

> - caching the results of regex replacement

If I understood correctly this won't help as an initial run of the
regexp also has this problem.

> - changing to a different regex library with performance
> characteristics more similar to whatever cmake is using

Thats something we always wanted to try out (I think cmake uses its own
implementation, I'd personally want to try out pcre), but never got
around to do (as QRegExp still is one of the major hotspots in the
profiles AFAIK)

Andreas

-- 
You will live to see your grandchildren.

-- 
KDevelop-devel mailing list
KDevelop-devel@kdevelop.org
https://barney.cs.uni-potsdam.de/mailman/listinfo/kdevelop-devel