search

ItzSomebody / radon

[Abandoned] Scuffed java bytecode obfuscator
GNU General Public License v3.0
361 stars 74 forks source link

Improve GRADLE build Performance #100

Closed shisheng-1 closed 1 year ago

shisheng-1 commented 2 years ago

Process forking options. Gradle will run all tests in a single forked VM by default. This can be problematic if there are a lot of tests or some very memory-hungry ones. We can fork a new test VM after a certain number of tests have run by setting forkEvery.

===================== If there are any inappropriate modifications in this PR, please give me a reply and I will change them.

Col-E commented 2 years ago

Generally speaking per-VM test cases are the way to go to ensure there isn't any cross contamination of values across test invocations. And here there's only one test class with 15 tests so there's not much to really worry about in any direction.

shisheng-1 commented 2 years ago

Hi @Col-E According to my tests, this makes the build faster. Tested using ./gradlew clean && ./gradlew build --scan

without forkEvery, the total build time is 4s

with forkEvery, the total build time is 3s

If the number of tests in this project increases, it is believed that the gap will be further widened and the improved performance will be more intuitive

ItzSomebody commented 2 years ago

Hi @shisheng-1. Sorry for the late reply, I have apparently forgotten to look at this.

I am looking through the build logs you linked, and I think your conclusion that forkEvery improves the build speed by an entire second for 15 tests is not correct. In fact, I would have been very surprised if forkEvery was faster for such a small number of tests.

Looking at through each log, you can see that the all of the tests were executed within marginal differences of each other (0.184s vs. 0.174s). Furthermore, the largest actual difference is an almost one second difference when executing the compileJava task.