[
https://issues.apache.org/jira/browse/LUCENE-9232?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17039044#comment-17039044
]
Dawid Weiss commented on LUCENE-9232:
-------------------------------------
{quote}bq. The first time you run the build, there's no gradle.properties, it
forks a daemon. it creates a new gradle.properties since that is what our build
does.
{quote}
Ah, this is a valid point... It does it because we alter JVM properties (heap).
I don't know how we can avoid this though. When you run it the first time it'll
fork a daemon – even if you put no-daemon options to gradle.properties that
first one is going to stay dormant in the background.
The timings you gave are only for script evaluation. The gain is (and I'm not
completely confident here, just guessing) that when you run something larger
(say "gradlew compile") caches of inputs/ outputs are reused.
Regardless of the default for daemon or no-daemon the initial run is indeed a
problem (I don't know how to solve it off the top of my head).
> disable gradle daemon by default
> --------------------------------
>
> Key: LUCENE-9232
> URL: https://issues.apache.org/jira/browse/LUCENE-9232
> Project: Lucene - Core
> Issue Type: Bug
> Reporter: Robert Muir
> Priority: Major
>
> We should disable the gradle daemon by default: the user can opt-in by
> changing the properties file.
> If you forget to do this, you end out with leaked JVMs everywhere. It won't
> just leak one daemon, it will leak multiple ones.
> I ran {{ps}} on my laptop, surprised at 13:00 to find 2 leaked gradle jvms
> when I hadn't used the thing since 07:00.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
---------------------------------------------------------------------
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
