Closed jeffdgr8 closed 3 months ago
Hi, class instrumentation modifies the class code to measure the execution of each line/branch of code - this increases the amount of bytecode, thereby disabling many JVM optimizations. Saving the fact of calling each line occurs in a common memory - this can have a big side effect in the form of performance degradation when intensively calling the same methods in parallel.
It is recommended to disable instrumentation during performance testing and concurrency tests.
Due to the Gradle build cache, task settings should depend only on the build configuration, but not on the list of tasks to run. Therefore, you can add a parameter to enable instrumentation if you need to generate a Kover report.
For example, add such code to each subproject:
kover {
if (!hasProperty("enableKover")) {
disable()
}
}
and pass the parameter to the command
./gradlew koverHtmlReport -PenableKover
Thanks for the clarification and workaround. I think this would be helpful to clarify this behavior in the README documentation.
Yes I have been doing somethig like -PenableKover
for a while now for exactly this reason.
Describe the bug I found that Kover slows down JVM test runs, in some cases when using parallel coroutines by a lot.
Expected behavior I was unaware that Kover was running on all JVM test runs, and not just when generating its reports. I would expect normal JVM test runs shouldn't be impacted by Kover.
I'd also expect parallel coroutines to not be significantly slower than running the same code sequentially.
Reproducer kover-slow-test.zip
Reports Running this test without Kover on a 16-core CPU:
Running with Kover:
The parallel coroutines take twice as long as running the same code sequentially. Sometimes the second parallel part of the test will take even longer. I observed up to 45 seconds.
Environment