dweiss commented on PR #11927:
URL: https://github.com/apache/lucene/pull/11927#issuecomment-1314869284
> It is best not to fork at all, forking is not wanted or helpful
Forking javac is needed under a few circumstances - when you want to use a
different version javac (which we support), when boostrap classpath is altered
(errorprone). By default it runs in-process and I think this is fine.
I'm not sure about setting active processor count to 1 for gradle itself...
This results in a weird configuration in which the jvm is configured for 1
processor but (on my amd ryzen) the worker defaults are set to 12:
```
# Maximum number of parallel gradle workers.
org.gradle.workers.max=12
```
Those workers are not necessarily forked subprocesses. I ran the patch vs.
main and it's less pronounced too, although per-task results are faster (as is
overall CPU consumption during the build):
main:
```
gradlew check -x test -Dvalidation.errorprone=true -Ptask.times=true
Aggregate task times (possibly running in parallel!):
189.16 sec. compileJava
108.24 sec. compileTestJava
91.89 sec. renderSiteJavadoc
80.15 sec. spotlessJava
64.31 sec. renderJavadoc
59.26 sec. ecjLintMain
53.56 sec. ecjLintTest
28.45 sec. rat
...
BUILD SUCCESSFUL in 2m 29s
736 actionable tasks: 735 executed, 1 up-to-date
```
patch:
```
Aggregate task times (possibly running in parallel!):
123.72 sec. compileJava
103.35 sec. compileTestJava
79.47 sec. renderSiteJavadoc
63.06 sec. renderJavadoc
54.20 sec. spotlessJava
43.24 sec. ecjLintMain
42.38 sec. ecjLintTest
31.48 sec. checkUnusedConstraints
25.01 sec. checkBrokenLinks
21.42 sec. validateSourcePatterns
19.88 sec. rat
...
BUILD SUCCESSFUL in 2m 22s
736 actionable tasks: 735 executed, 1 up-to-date
```
I don't quite understand what's happening above but since it does make a
difference on slower machines and makes literally no difference on beefier
ones, I'm fine with applying the patch.
The 3gb heap is, I believe, a remnant of the past - gradle daemon OOMing
sometimes. Perhaps it's been fixed.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
