mikemccand commented on PR #414: URL: https://github.com/apache/lucene/pull/414#issuecomment-1793485933
> > I don't like how slow our gradle builds are, so if we can make it faster, that'd be awesome. > > Are they? What in particular is slow for you, Mike? There's tons of stuff that runs on (full) check across all submodules, for example. I don't think it's avoidable. In majority of cases, you can narrow down the task to a subproject and it runs very quickly for me. Well, maybe I am too impatient. I don't have hard data to prove they are slow. But if I watch `top` while running toplevel `./gradlew test` I am disappointed at how much concurrency is left on the table. I do see lots of concurrency (many `java` processes) when the actual unit testing seems to start, which is great. With my `lucene` clone already fully compiled, the gradle build seems to take a few (~3) seconds to confirm everything is up-to-date, printing out lines like `> Task :lucene:benchmark:jar UP-TO-DATE `. This is on a modern Raptor Lake Intel CPU. So yeah I retract my statement :) It's not clearly slow. `./gradlew test` finishes in 56s for me (on fully built clone). I remember times in the past when this was much longer ... thanks @dawid and @clayburn. -- 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: issues-unsubscr...@lucene.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org --------------------------------------------------------------------- To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
