You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
This PR reworks how LF and unit tests are built and executed. Instead of compiling reactor-uc from scratch for each LF test via the Makefile, we now use CMake to share a single reactor-uc build across all tests and compile them in parallel.
I also added a batch processing function in lfc.cmake so we can invoke LFC once for multiple test files instead of calling it repeatedly, and added coverage support for LF tests (previously we only had it for unit tests).
Minor changes:
Moved federated LF tests into test/lf/src/federated/ with a dedicated runner script;
Improved runtime symlink handling in UcPlatformGenerator.kt;
Fixed a couple of ASAN errors in connection logging and the event payload pool test;
Cleaned up the build config so unit tests and LF tests are properly decoupled.
Makefile (compiles reactor-uc per test, sequential)
1210s
CMake (shared reactor-uc, -j16)
182s
Speedup
6.6x
CMake breakdown:
LFC generation (cmake configure): ~101s
Compilation: ~18s
Test execution (ctest): ~63s
We can squeeze more out of this:
Batch generation in LFC for federates: LFC reports an error if the batch contains more than one main federate. Currently, we still must process each federate individually, adding a lot of overhead.
Move re-generation checks inside LFC: Currently, when a .lf file has already been built, LFC re-executes the entire generation pipeline and checks for each file whether the output it wants to write matches what's already on disk. Instead, we could take the same approach as make and check whether the output directory was modified more recently than the .lf file and its imports. This would allow us to cache the generated output in the CI pipeline and skip the generation step entirely when the tests haven't changed.
The reason will be displayed to describe this comment to others. Learn more.
LGTM, but I did not check it carefully. I would say, if it works, and you are sure all tests are running, go for it. I would be curious to know how much it speeds up the CI tests.
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
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.
This PR reworks how LF and unit tests are built and executed. Instead of compiling reactor-uc from scratch for each LF test via the Makefile, we now use CMake to share a single reactor-uc build across all tests and compile them in parallel.
I also added a batch processing function in
lfc.cmakeso we can invoke LFC once for multiple test files instead of calling it repeatedly, and added coverage support for LF tests (previously we only had it for unit tests).Minor changes:
test/lf/src/federated/with a dedicated runner script;UcPlatformGenerator.kt;Closes #275 and #136.
Benchmark
This is the improvement I got on my laptop:
-j16)CMake breakdown:
We can squeeze more out of this:
.lffile has already been built, LFC re-executes the entire generation pipeline and checks for each file whether the output it wants to write matches what's already on disk. Instead, we could take the same approach asmakeand check whether the output directory was modified more recently than the.lffile and its imports. This would allow us to cache the generated output in the CI pipeline and skip the generation step entirely when the tests haven't changed.