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.smi...@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 <erickerick...@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....@cominvent.com> wrote: >> > >> > gradlew -p solr/packaging assemble >> >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org >> For additional commands, e-mail: dev-h...@lucene.apache.org >> --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
