FindOpenSSL slow and not cached on Windows ?

Usage
1

Hi, I’m investing why our CMake configuration takes really much longer time on Windows than macOS and Linux.
I’m already aware that Windows filesystem and Windows defender is one of the culprit.
However, I profile the configure time of our big library project (that expose multiple libraries).
Due to, separation of concern, and architecture of multiple libraries that we could built separately, we may call multiple times find_package of the same lib.
The documentation of find_package says :

Once one of the calls succeeds the result variable will be set and stored in the cache so that no call will search again.

So this should not be a problem.

The profile show us the opposite :

image
image1520×303 24.4 KB

We can see 8 calls to find_package of OpenSSL that each tooks : 5,5 secs.
So it tooks around 45 sec just for OpenSSL. Some calls are direct calls from us, some of them are dependency calls from CURL or jwt-cpp.
The other find_package calls are short compare to OpenSSL, we can’t see them on picture due to OpenSSL oversize. For example with libuv (37ms), libssh(40ms), ffmpeg(1,2 secs quite long but ok),…

So I have 2 questions :

  • Why find_package(OpenSSL REQUIRED) takes so long ?
  • Why, once libssl and libcrypto found, the result is not cached ?

Additional resources:

I wrote a sandbox code that looks like this → 

cmake_minimum_required(VERSION 3.15)

project(sandbox)

set(CMAKE_PREFIX_PATH "A REALLY LONG PATH LIST, COPY-PASTE FROM OUR PROJECT TO MATCH PATH SEARCH COMPLEXITY")

find_package(OpenSSL REQUIRED)
find_package(OpenSSL REQUIRED)
find_package(CURL REQUIRED)
find_package(CURL REQUIRED)

add_executable(sandbox main.cpp)
target_link_libraries(sandbox PRIVATE OpenSSL::SSL OpenSSL:Crypto CURL::libcurl)

Result :

  • 1st find_package(OpenSSL REQUIRED) : 289ms
  • 2nd find_package(OpenSSL REQUIRED) : 237ms
  • 1st find_package(CURL REQUIRED) : 240ms ( 233ms for OpenSSL dependency)
  • 2nd find_package(CURL REQUIRED) : 5ms

First, CURL cache properly his result. OpenSSL not.
Then, find_package takes around 250ms for OpenSSL, so far from 5/6 secs in our project.|

EDIT1:
I noticed that for example our CURL lib build comes with CURLConfig.cmake despite OpenSSL that use CMake Module FindOpenSSL that have to manually search for library and include paths. It can explain the long time for OpenSSL but not the uncached result.

2

This sentence from the find_package() documentation is in the Config Mode Search Procedure section. OpenSSL is being found via Find module mode, so that sentence doesn’t apply. The behavior of a Find module is completely up to the implementation of that module. In OpenSSL’s case, it appears to be not using cache variables efficiently to cache details from a prior call. There could be any number of reasons for that, you’d have to crawl through its implementation to find out why.

1 Like
3

I will check in this direction, BTW I saw that starting from OpenSSL 3.3.X they start providing an OpenSSLConfig.cmake file in there github repository. Since OpenSSL 1.1.1 is not supported anymore, It could be a solution.
Thanks for the detail between config mode en find module mode :+1: