lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Erick Erickson <erickerick...@gmail.com>
Subject Re: Gradle build effort (respin, please read)
Date Tue, 03 Dec 2019 21:25:17 GMT
Here’s what I have in ~/.gradle/gradle.properties that seems to at least be in the right
ballpark. Based on Mark’s “intro to the gradle build” page:


// the project version
version=9.0.0

// whether or not to use the Gradle daemon - if true, keeps the build process around for reuse
for up to 3 hours so that startup times are removed and hotspot has a chance to rock - you
should generally set this to true in your ~/.gradle/gradle.properties
// we set to false so that a CI system with no setting will not use a daemon by default
org.gradle.daemon=true

// allows tasks to be executed in parallel, across modules
org.gradle.parallel=true

// max parallel jobs to run at once, including both tasks and tests.
// default is number of CPU cores which is often too high - you should start by setting it
to half the number of cores, especially if you have hyperthreading
org.gradle.workers.max = 6

// number of jvms to distribute tests across in parallel
// defaults to number of CPU cores / 2 - you should just set this the same as org.gradle.workers.max
// NOTE: gradle does not try to balance tests across jvms yet: https://github.com/gradle/gradle/issues/2669
tests_jvms = 6

// enables gradles build cache, which will reuse cached build outputs when it can
org.gradle.caching=true

// experimental gradle feature - does not currently work with our version constraints plugin:
https://github.com/palantir/gradle-consistent-versions/pull/145
// also known to have other issues and not known to really speed anything up anyhow
org.gradle.configureondemand=false

// how much ram the gradle daemon or process can use
org.gradle.jvmargs=-Xmx1g


> On Dec 3, 2019, at 3:57 PM, Dawid Weiss <dawid.weiss@gmail.com> wrote:
> 
> That's aligned with my intuition -- logical cores / 2. Sadly I don't
> see how we may compute the number of workers dynamically (you can do
> this with test forks per project but not with the overall number of
> workers). I asked about it [1]. This is perhaps one of the few
> settings you could override globally via ~/.gradle/gradle.properties
> because it really applies to your hardware (corrects the overestimated
> default by Gradle).
> 
> org.gradle.workers.max=[cpu cures]/2
> 
> D.
> 
> [1] https://discuss.gradle.org/t/set-max-workers-dynamically/34087
> 
> On Tue, Dec 3, 2019 at 9:19 PM David Smiley <david.w.smiley@gmail.com> wrote:
>> 
>> FWIW on a 6 year old MacBook Pro with a Quad-core i7, it seems max-workers of 2 is
about right, clocking in at 21:32.  3 took 20:17; not much better.
>> 
>> ~ David Smiley
>> Apache Lucene/Solr Search Developer
>> http://www.linkedin.com/in/davidwsmiley
>> 
>> 
>> On Tue, Dec 3, 2019 at 9:13 AM Erick Erickson <erickerickson@gmail.com> wrote:
>>> 
>>> David Smiley:
>>> 
>>> gradlew -p solr/packaging assemble
>>> 
>>> couple of things:
>>> 1> The place you run bin/solr from is different
>>> 2> I didn’t need to specify the -p parameter and it defaulted to ‘...solr/packaging/build/solr-9.0.0-SNAPSHOT',
FWIW.
>>> 
>>> Once I got over having to switch to a different dir than I was accustomed to,
I realized that by not mixing the build output with source, things are _much_ cleaner. After
a “gradlew clean”, the packaging directory only contains a build.gradle file.
>>> 
>>>> On Dec 3, 2019, at 4:48 AM, Jan Høydahl <jan.asf@cominvent.com> wrote:
>>>> 
>>>> gradlew -p solr/packaging assemble
>>> 
>>> 
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
>>> For additional commands, e-mail: dev-help@lucene.apache.org
>>> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
> For additional commands, e-mail: dev-help@lucene.apache.org
> 


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org


Mime
View raw message