CMAKE_FIND_PACKAGE_PREFER_CONFIG=ON causes long configure times
Hello all,
we are building and maintaining bunch of third-party packages in our project. Many C++ Packages include their own Config.cmake file, even if the CMame FindPackage is delivered by CMake. To ensure, that all libraries in our project do not mixup Config and Module methods of Package Lookup we would like to use CMAKE_FIND_PACKAGE_PREFER_CONFIG=ON. This option does the trick and everything runs nicely.... on Linux. On Windows we found out, that enabling CMAKE_FIND_PACKAGE_PREFER_CONFIG causes Configure Step to take like 2-6x more time then without. I've profiled the step and came up with pretty small example which demonstrates the issue.
cmake_minimum_required(VERSION 3.20)
project(findpackage_profile)
find_package(Boost REQUIRED COMPONENTS date_time)
add_executable(main main.cpp)
target_link_libraries(main Boost::date_time)
And correspondingly
D:\development\install\cmake\cmake-3.26.0-windows-x86_64\bin\cmake.exe -G Ninja -S . -B build "-DCMAKE_PREFIX_PATH=D:\development\efa\default\.cache\3rdparty\x64\v142_x64-windows\installed\v142_x64-windows" "-DCMAKE_FIND_ROOT_PATH=D:\development\efa\default\.cache\3rdparty\x64\v142_x64-windows\installed\v142_x64-windows" -DCMAKE_FIND_PACKAGE_PREFER_CONFIG=OFF --profiling-format=google-trace --profiling-output=fast_3.26.txt
D:\development\install\cmake\cmake-3.26.0-windows-x86_64\bin\cmake.exe -G Ninja -S . -B build "-DCMAKE_PREFIX_PATH=D:\development\efa\default\.cache\3rdparty\x64\v142_x64-windows\installed\v142_x64-windows" "-DCMAKE_FIND_ROOT_PATH=D:\development\efa\default\.cache\3rdparty\x64\v142_x64-windows\installed\v142_x64-windows" -DCMAKE_FIND_PACKAGE_PREFER_CONFIG=ON --profiling-format=google-trace --profiling-output=slow_3.26.txt
In Attachmend you find two profile traces. fast_3.26.txt slow_3.26.txt
For Illustratin also pictures: Slow: Fast:
If you look for the find_package call with and without 'prefer' flag active you'll see, that the attemt to find Package Configuration takes (in this example) 150ms. Even though the time seems insignificant, if you consider some (not really big) project, with maybe 50 libraries, which are trying to find the packages they need. And every library needs maybe has several packages (let's assume 3) 150ms * 50 * 3 ~= 22.5s. If you consider, that some Package-Configurations like to find their own dependencies too, you can end up in pretty ugly situation. In our project this explodes configure times from several seconds to one or two minutes.
The problem doesn't affect Linux that much.
So the question/bug is: what is really happening on windows? Why does find_package-miss takes so much time. I would assume, it's just quick search through directory tree (which is not that big either) with pretty straightforward pattern.
Or am I doing something wrong? We ruled out the effects of Antivirus software by removing it from our test system completely. Maybe you have any Ideas?