[go: nahoru, domu]

Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[FR]: The time cost of find_packe for Python is longer than expected #4424

Closed
GengGode opened this issue Dec 1, 2023 · 0 comments
Closed
Assignees

Comments

@GengGode
Copy link
GengGode commented Dec 1, 2023

Does the feature exist in the most recent commit?

not find

Why do we need this feature?

In my project I added gtest via fetch function and then I noticed the obvious wait and felt tortured. Then the "NOTfind Python3" message appeared in the logs. I've noticed that this is the longest part of my project configuration process.

[cmake] -- Could NOT find Python3 (missing: Python3_EXECUTABLE Interpreter) 
include(FetchContent)
FetchContent_Declare(gtest GIT_REPOSITORY https://github.com/google/googletest.git GIT_TAG v1.14.0)
FetchContent_MakeAvailable(gtest)

I found that there is a find_package (Python3) in file internal_utils.cmake, and it does not belong to any function or macro, which is very inconsistent.
Then I noticed that py_xxx is only used when gtest_build_tests is enabled. So I boldly deleted find_package(Python3).
The effect is dramatic and the waiting is almost invisible. It seems certain that the time-consuming operation is here.
For the sake of rigor, I wrote a simple cmake project to measure the related time-consuming.
CMakeLists.txt

cmake_minimum_required(VERSION 3.15)
project(test)
include(FetchContent)

set(CTIME_STRING "%Y-%m-%d %H:%M:%S")
set(CTIME_STAMP "%s")
string(TIMESTAMP begin_time ${CTIME_STRING})
string(TIMESTAMP begin_time_stamp ${CTIME_STAMP})
message(STATUS "Current time: ${begin_time}  ${begin_time_stamp}")
#FetchContent_Declare(gtest GIT_REPOSITORY https://github.com/google/googletest.git GIT_TAG v1.14.0)
#FetchContent_MakeAvailable(gtest)
find_package(Python3)

string(TIMESTAMP end_time ${CTIME_STRING})
string(TIMESTAMP end_time_stamp ${CTIME_STAMP})
message(STATUS "Current time: ${end_time}  ${end_time_stamp}")
math(EXPR diff_time "${end_time_stamp} - ${begin_time_stamp}")
message(STATUS "Time difference: ${diff_time} seconds")

The results are as follows.

[cmake] -- Current time: 2023-12-02 04:59:48  1701464388
[cmake] -- Could NOT find Python3 (missing: Python3_EXECUTABLE Interpreter) 
[cmake] -- Current time: 2023-12-02 04:59:54  1701464394
[cmake] -- Time difference: 6 seconds

After some googling, I didn't find any relevant information about the time overhead of find_package :(

Considering that not everyone may use the gtest part, but according to the reference of internal_utils.cmake, this sentence will be executed no matter how the variables are set.

I hope to find_package only when the gtest_build_tests variable is ON.

Describe the proposal.

Wrapped by if(gtest_build_tests) outside find_package(Python3)

# old
find_package(Python3)
# new
if(gtest_build_tests)
  find_package(Python3)
endif()

I want to skip this time-consuming operation when I don't need to test, even though it's not too long for me:)

image

internal_utils.zip
CMakeLists.txt

This is the improved measurement result( Forgive my poor coding skills, I can only measure one second at the very least

[cmake] -- Current time: 2023-12-02 05:14:35  1701465275
[cmake] -- Current time: 2023-12-02 05:14:35  1701465275
[cmake] -- Time difference: 0 seconds

Is the feature specific to an operating system, compiler, or build system version?

I only have a Windows 10 computer, so I only tested it on this PC.
I tested version 1.14.0 and checked the code of master, they are consistent(Except for different versions of Python)

-G "Visual Studio 17 2022" -T host=x64 -A x64
Windows SDK version 10.0.22621.0 to target Windows 10.0.19045.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants