Try using low Gradle priority instead of capping workers

[anuraaga]

Gradle team recommended trying this setting - can anyone else check if it helps with their builds? Even so, I'm worried it will still be too much for CI but let's see what happens. For me locally, build seems to be going reasonably fast without bogging down computer.

[anuraaga]

Since this PR build can all come from cache, not representative of whether this flag negatively affects the CI 😿

[iNikem]

Do we have performance-related problems with CI lately? I don't think so.

I am trying to better understand and separate two problems: local builds and CI builds. If we have problems with local builds only, they all are fixable by ~/.gradle/gradle.properties and proper documentation. I think current configuration is adequate for the CI

[anuraaga]

The current default is probably good for CI - but indeed if I don't set the workers higher the build feels very slow locally. max-workers=4 works well for me but this priority setting also worked well I think. But it's not a scientific result :)

Since we control CI, we can set the properties there to anything we want so I think it could be good to have this file to default to the best local build experience. max-workers=2 isn't for me and I think priority=low might be a reasonable, hw-agnostic default. But need more testers.

If this makes sense I'll go ahead and tweak the CI files to restore normal priority + max-workers=2 there to make sure that doesn't degrade. Let me know how it goes

[iNikem]

I will try.

Gradle team recommended trying this setting

Can you point me to this?

[iNikem]

I am not sure if this new setting is better or worse than the old one, but this new one works fine for me on two different Macs.

[trask]

wow, that setting is almost magical on my machine 😲

100% cpu utilization, but machine is still responsive, unlike before

let's merge and give it a longer term spin

[anuraaga]

@iNikem Sorry for late reply, Gradle team response is at gradle/gradle#14224