Silly CMake 2.8.2 regex causing slow project load in KDevelop

[Milian Wolff]

On Monday 19 July 2010 09:10:37 Andreas Pakulat wrote:
> 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)

Not as bad as it used to afaiks. But it's of course still slow(er). Didn't 
Google also release one of their libs under a FOSS license which was 
supposedly even faster than what the rest of the market could give?

Bye
-- 
Milian Wolff
mail at milianw.de
http://milianw.de
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/kdevelop-devel/attachments/20100719/e3a93961/attachment.sig>