MantisBT - CMake
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0011005CMakeCMakepublic2010-07-17 08:002010-08-04 00:48
ReporterCarlo Wood 
Assigned ToKovarththanan Rajaratnam 
PrioritynormalSeverityminorReproducibilityalways
StatusclosedResolutionfixed 
PlatformOSOS Version
Product VersionCMake-2-8 
Target VersionFixed in VersionCMake-2-8 
Summary0011005: FindZLIB takes "forever"
DescriptionFindZLIB takes 6.6 seconds. This is new for me since I upgraded my GNU/Linux
debian testing (squeeze) recently. Before was using only a fraction of a second.

This problem is caused by doing a
STRING(REGEX REPLACE ".*#define ZLIB_VERSION \"([0-9]+)\\.([0-9]+)\\.([0-9]+)\".*" "\\1.\\2.\\3" ZLIB_VERSION_STRING "${ZLIB_H}")
in FindZLIB.cmake on the complete contents of zlib.h.

I'm not exactly sure what the reason is that this has to take 6.6 seconds,
it seems to me that it should be able to do this faster; so the problem
might actually lay in having an inefficient regular expression search.
Steps To Reproduce
Additional InformationThe project that I'm working on uses include's in every CMakeLists.txt file,
all of which seem to need to include an Common which includes FindZLIB.
The result: configuring takes 4 minutes and 22 second. After taking out the
regular expression search (that finds the version of zlib), configuring takes
6 seconds.

The reproduce, create a file CMakeLists.txt with the contents:

cmake_minimum_required(VERSION 2.8)
include(FindZLIB)

Then run:

>rm CMakeCache.txt; time cmake .-- The C compiler identification is GNU
-- The CXX compiler identification is GNU
-- Check for working C compiler: /usr/bin/gcc
-- Check for working C compiler: /usr/bin/gcc -- works
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Check for working CXX compiler: /usr/bin/c++
-- Check for working CXX compiler: /usr/bin/c++ -- works
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
-- Found ZLIB: /usr/include
-- Configuring done
-- Generating done
-- Build files have been written to: /usr/src/debian/cmake/test

real 0m6.595s
user 0m6.456s
sys 0m0.116s

TagsNo tags attached.
Relationships
Attached Files
Issue History
Date ModifiedUsernameFieldChange
2010-07-17 08:00Carlo WoodNew Issue
2010-07-17 08:02Carlo WoodNote Added: 0021416
2010-07-17 08:02Carlo WoodNote Edited: 0021416
2010-07-17 08:05Carlo WoodNote Edited: 0021416
2010-07-17 21:45Nicolás AlvarezNote Added: 0021418
2010-07-17 21:47Nicolás AlvarezNote Edited: 0021418
2010-07-17 22:25Nicolás AlvarezNote Added: 0021419
2010-08-03 12:14Kovarththanan RajaratnamStatusnew => assigned
2010-08-03 12:14Kovarththanan RajaratnamAssigned To => Kovarththanan Rajaratnam
2010-08-04 00:48Kovarththanan RajaratnamNote Added: 0021623
2010-08-04 00:48Kovarththanan RajaratnamStatusassigned => closed
2010-08-04 00:48Kovarththanan RajaratnamResolutionopen => fixed
2010-08-04 00:48Kovarththanan RajaratnamFixed in Version => CMake-2-8

Notes
(0021416)
Carlo Wood   
2010-07-17 08:02   
(edited on: 2010-07-17 08:05)
The version of zlib that I have installed is:

||/ Name            Version               Description
+++-================-=====================-================================
ii  zlib1g-dev      1:1.2.3.4.dfsg-3      compression library - development


(0021418)
Nicolás Alvarez   
2010-07-17 21:45   
(edited on: 2010-07-17 21:47)
KDevelop's CMake parser takes *four minutes* to apply this regex replacement, due to the performance of QRegExp, making projects that use FindZLIB take that long to load.

Real CMake takes 10 seconds, which I consider still unacceptable (compared to the speed of other Find* modules).

To make things worse, the regex *doesn't even work* on my machine, because ZLIB_VERSION on my system zlib.h has four version components ("1.2.3.4").
(0021419)
Nicolás Alvarez   
2010-07-17 22:25   
Apparently, if zlib.h has three components, making the regex work at all, both CMake and KDevelop take a fraction of a second.
(0021623)
Kovarththanan Rajaratnam   
2010-08-04 00:48   
Nicolás, I've submitted a patch as part of bug 0011049. Can you check the latest master?