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 <[email protected]> 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 <[email protected]> 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 <[email protected]> >> 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 <[email protected]> wrote: >>>> >>>> gradlew -p solr/packaging assemble >>> >>> >>> --------------------------------------------------------------------- >>> To unsubscribe, e-mail: [email protected] >>> For additional commands, e-mail: [email protected] >>> > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
