Remove org.gradle.parallel=true from gradle.properties

[trask]

Currently we have org.gradle.parallel=true specified in our gradle.properties. This makes my machine grind to a halt during the builds. I can fix this by adding org.gradle.workers.max to my ~/.gradle/gradle.properties, but I'm not sure that org.gradle.parallel=true provides the best new contributor experience.

[iNikem]

This is extremely curious, as this is the first project that I participate in that bogs developer machine down. I really would like to understand why is this happening.

Without parallel local build will be very long. But at least it will end... If we remove it, I think we should at least reference Gradle documentation about configuring it locally.

[anuraaga]

Same as @iNikem I've dealt with a couple of large Gradle projects before and parallel has never brought my system down like this one does. I suspect something wrong with our build - I have 4 hyperthread cores so I'd expect either 4 or 8 parallel tasks given the default is supposed to be num CPUs, but this build has 12 parallel tasks on my computer.

[anuraaga]

Randomly noticed today, the max workers does seem to be the correct 8 during initial compilation tests. It's only as tests start to run that it adds more workers for some reason. Never seen that o_O

[anuraaga]

Also noticed that it always adds 4 extra workers. --max-workers=8 doesn't fix the issue (which does make sense since it's the Gradle default on my laptop), so I use --max-workers=4 and end up with 8 workers

[anuraaga]

With the finalizeBy change I noticed my build runs test then integrationTest in order, an observation is test never results in workers past the max-workers, it's only during integrationTest that it happens. So possibly something about SpockRunner. No clue what it could be just recording observations :)

[iNikem]

@open-telemetry/java-instrumentation-approvers Please vote 👍 or 👎 for this proposal.

[anuraaga]

I'm neutral TBH - both non-parallel and parallel without max-workers seem too slow for builds in general.

Anyone with friends at Gradle to backchannel my gradle/gradle#14224? :)

[trask]

How about adding this to gradle.properties instead:

// limiting the number of parallel workers helps to keep your machine responsive during builds
// see https://github.com/gradle/gradle/issues/14224
org.gradle.workers.max=2

under the assumption that most dev machines have 4+ cores.

[iNikem]

I am Ok both with the original Trask's idea of removing and with new idea of replacing with max workers. Both can be overridden locally.

[tylerbenson]

I support setting the default max instead of removing the parallel setting. I would propose 3/4 workers though with the understanding that we do a fair bit of blocking in our tests, so a small amount of over provisioning is probably fine.

[trask]

This is what org.gradle.workers.max=3 does to my 6 core machine 😭

[tylerbenson]

@trask doesn't that show good execution? I assume it would be much less utilized without parallel enabled.

[trask]

it would be good if I wasn't trying to do anything else on my machine at the same time, it took 15 seconds just to open screen capture tool to get that picture 😭