# FindOpenSSL slow and not cached on Windows ?
**URL:** https://discourse.cmake.org/t/findopenssl-slow-and-not-cached-on-windows/13532
**Category:** Usage
**Tags:** os:windows
**Created:** [February 4, 2025, 9:23am UTC](https://discourse.cmake.org/t/findopenssl-slow-and-not-cached-on-windows/13532 "2025-02-04T09:23:52Z")
**Posts on this page:** 3
**Page:** 1
### Author:  [@pcorbineau](https://discourse.cmake.org/u/pcorbineau)
#### Post date: [February 4, 2025, 9:23am UTC](https://discourse.cmake.org/t/findopenssl-slow-and-not-cached-on-windows/13532/1 "2025-02-04T09:23:52Z")
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 :
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
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.
---
### Author:  [@craig.scott](https://discourse.cmake.org/u/craig.scott)
#### Post date: [February 4, 2025, 8:54pm UTC](https://discourse.cmake.org/t/findopenssl-slow-and-not-cached-on-windows/13532/2 "2025-02-04T20:54:06Z")
> [@pcorbineau](#):
>
> Once one of the calls succeeds the result variable will be set and stored in the cache so that no call will search again.
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.
---
### Author:  [@pcorbineau](https://discourse.cmake.org/u/pcorbineau)
#### Post date: [February 5, 2025, 8:09am UTC](https://discourse.cmake.org/t/findopenssl-slow-and-not-cached-on-windows/13532/3 "2025-02-05T08:09:53Z")
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 👍