Open seanpianka opened 4 months ago
Thanks for the report! Is this a problem that only occurs when combined with nextest? Or is this a problem that also occurs when using cargo-llvm-cov without nextest?
I have not seen the code, but in the latter case I wonder if it is the same problem as with https://github.com/taiki-e/cargo-llvm-cov/issues/371.
Alpine 3.19, Docker
I have heard that some std APIs are very slow in musl (https://github.com/taiki-e/install-action/issues/13), so maybe that is the problem...?
Description
This issue occurs with numerous tests ran within a suite of 415 other tests. The vast majority of these tests are of the same complexity as the test shown below (i.e.: simple methods which set a boolean field from
false
totrue
and assert it as such).Using
nextest
withllvm-cov
significantly slows test execution. A simple test takes over 42 seconds with coverage enabled, compared to under one second without it. The process to generate the line coverage data seems to be placing my CI runner's host under significant memory or I/O load.Test Example
Execution Time
With llvm-cov used to invoke the
nextest run
command, I see execution times similar to the following:or
The execution times are highly variable, depending on the load and which specific process gets prioritized at what time.
However, when I invoke
cargo nextest run
directly (with similar flags), the execution time falls significantly.or
Environment
docker:26.1.3-dind-alpine3.19
), GitLab CI on self-managed runner (Intel(R) Core(TM) i7-9700K CPU @ 3.60GHz, 32GB DDR4 memory)Steps to Reproduce
Add the test in
src/lib.rs
:llvm-cov
and observe the execution time.Additional Information
Command:
Config:
Other Tests: Execution times vary widely, with some simple tests taking up to 60 seconds.
Findings
Originally, I opened an issue here with nextest directly. However, I found that stripping
llvm-cov
from the command reduces test execution times to under one second for most tests, indicating that generating coverage results significantly impacts CPU, memory, and/or I/O load.Command without
llvm-cov
Please let me know if you need further information or additional logs.
Thank you for your help!