--===============1618843128==
Content-Type: multipart/signed;
  boundary="nextPart5313453.WubDv0vjrW";
  protocol="application/pgp-signature";
  micalg=pgp-sha1
Content-Transfer-Encoding: 7bit

--nextPart5313453.WubDv0vjrW
Content-Type: Text/Plain;
  charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

On Monday 19 July 2010 09:10:37 Andreas Pakulat wrote:
> On 18.07.10 23:35:36, Nicol=E1s 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
> >=20
> > FindZLIB.cmake:
> >    FILE(READ "${ZLIB_INCLUDE_DIR}/zlib.h" ZLIB_H)
> >    STRING(REGEX REPLACE ".*#define ZLIB_VERSION
> >=20
> > \"([0-9]+)\\.([0-9]+)\\.([0-9]+)\".*" "\\1.\\2.\\3"
> > ZLIB_VERSION_STRING "${ZLIB_H}")
> >=20
> > 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.
> >=20
> > There is a CMake bug reported about this:
> > http://www.itk.org/Bug/view.php?id=3D11005
> >=20
> > 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(!).
> >=20
> > Is there anything we could do in KDevelop to work around the stupidity
> > in this CMake release? :) At the moment my only ideas are:
> >=20
> > - adding a workaround for this particular regex (a solution worthy of
> > Microsoft :P yuuuuck!)
>=20
> Not an option. We're also not adding workaround for Qt bugs most of the
> time.
>=20
> > - caching the results of regex replacement
>=20
> If I understood correctly this won't help as an initial run of the
> regexp also has this problem.
>=20
> > - changing to a different regex library with performance
> > characteristics more similar to whatever cmake is using
>=20
> 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=
=20
Google also release one of their libs under a FOSS license which was=20
supposedly even faster than what the rest of the market could give?

Bye
=2D-=20
Milian Wolff
mail@milianw.de
http://milianw.de

--nextPart5313453.WubDv0vjrW
Content-Type: application/pgp-signature; name=signature.asc 
Content-Description: This is a digitally signed message part.

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)

iEYEABECAAYFAkxEKp4ACgkQDA6yEs0dE5OZDQCeORsVxPJG1L5kB/NlIT3mvM9B
0eUAn3g06JNYp6IvmK0sP4xmbAm4fDpV
=A6XB
-----END PGP SIGNATURE-----

--nextPart5313453.WubDv0vjrW--


--===============1618843128==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

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

--===============1618843128==--