Speed up CTest, particularly for RDataFrame#19702
Merged
hageboeck merged 2 commits intoroot-project:masterfrom Oct 14, 2025
Merged
Speed up CTest, particularly for RDataFrame#19702hageboeck merged 2 commits intoroot-project:masterfrom
hageboeck merged 2 commits intoroot-project:masterfrom
Conversation
pcanal
reviewed
Aug 20, 2025
pcanal
reviewed
Aug 20, 2025
Test Results 22 files 22 suites 3d 14h 48m 59s ⏱️ Results for commit 6912bc9. ♻️ This comment has been updated with latest results. |
dpiparo
approved these changes
Aug 21, 2025
pcanal
reviewed
Aug 22, 2025
This was referenced Aug 30, 2025
Contributor
|
For the |
hageboeck
force-pushed
the
fasterCTest
branch
from
0dc047e to
c166439
Compare
hageboeck
force-pushed
the
fasterCTest
branch
from
c166439 to
afea782
Compare
hageboeck
force-pushed
the
fasterCTest
branch
from
43d3d52 to
6d6d2ee
Compare
In addition to correctly specifying the number of CPUs in CMake, the tutorials were also setting a resource lock, which prevented them from running in parallel with other RDF tutorials. Since ROOT honours ROOT_MAX_THREADS, this resource lock can be removed. Co-authored-by: Philippe Canal <pcanal@fnal.gov>
In roottest, targets are occasionally added to the Ninja build graph. These may be built as part of the test suite, possibly creating race conditions when Ninja is invoked from multiple tests. Therefore, all these builds were flagged with RUN_SERIAL, significantly reducing the parallelism of ctest. Therefore: - Add a test fixture to refresh the build tree. It is run before any test that invokes Ninja. The fixture runs in complete isolation to avoid any errors in tests that are started in parallel with the Ninja build. - Add "RESOURCE_LOCK NINJA_BUILD" to all tests that invoke Ninja. This ensures that only one Ninja process runs at any given point. In conjuction with the above fixture, this ensures that the Ninja build only touches the test executable, while targets that are part of "ninja all" are unaffected. This fact allows tests that come out of "ninja all" to run in parallel with tests that invoke Ninja on test executables.
hageboeck
force-pushed
the
fasterCTest
branch
from
6d6d2ee to
6912bc9
Compare
Member
Author
|
The mac14 failure happens intermittently also in master, so seemingly unrelated. |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
4 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Allow Ninja compilation in CTest to run in parallel with other tests
roottest Ninja targets are rebuilt as part of a ctest run. If two tests invoke Ninja, race conditions will occur.
To prevent that, ROOT used to run all tests with Ninja compilation in complete isolation, which can lead to a very long tail of tests that only keep a single core busy.
Here, the RUN_SERIAL property is removed, and a
RESOURCE_LOCKis employed to ensure that only one Ninja process runs at any given time, but that process may run in parallel with pre-compiled tests. In order to ensure that there is no interference with the pre-compiled tests:Note that this prevents users from recompiling only one single package and invoking a test that runs Ninja, while leaving the rest of the build tree outdated, since the entire build tree will be refreshed by the test fixture. I consider this use case a very niche case, though, since it is anyway very fragile because of frequent problems with outdated pcms, so it is usually best to complete the build.
Allow multi-threaded RDF tutorials to run in parallel with others
ROOT used to forbid running an MT RDF tutorial in parallel with another MT RDF tutorial. When running
ctest -R dataframe -jN, this can lead to a long tail of tutorials running completely sequentially. Nevertheless, since ROOT honoursROOT_MAX_THREADS, each was only running with 4 cores.Here, the strict
RESOURCE_LOCKis removed, and CMake is just informed about the required number of CPU cores. This allows for running a few of the MT tutorials in parallel.