[prev in list] [next in list] [prev in thread] [next in thread]
List: kdevelop-devel
Subject: Re: Silly CMake 2.8.2 regex causing slow project load in KDevelop
From: Milian Wolff <mail () milianw ! de>
Date: 2010-07-19 10:36:14
Message-ID: 201007191236.14906.mail () milianw ! de
[Download RAW message or body]
[Attachment #2 (multipart/signed)]
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@milianw.de
http://milianw.de
["signature.asc" (application/pgp-signature)]
--
KDevelop-devel mailing list
KDevelop-devel@kdevelop.org
https://barney.cs.uni-potsdam.de/mailman/listinfo/kdevelop-devel
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic