Thanks for asking, I planned to raise this topic soon in the mailing list Here you can find a presentation board https://miro.com/app/board/uXjVLYUPRas=/ which also has a 5 minute video with explanation (click Play on the first slide, no auth is required).
Long story short: standard Maven builder (either single or multi-threaded) has a pretty strong contract: it schedules the module to be built not earlier than all upstream dependencies are resolved (if it's a jar library - it's downloaded from remote to .m2, if it's another module - ALL build phases are executed). And it's a bottleneck in multi-module projects built on multi-core CPUs. It looks like takari-smart-builder respects this contract, but schedules modules in different order, also resolving libraries eagerly for optimization purposes. The maven-turbo-builder is a more radical change: 1. it schedules downstream dependency build once the upstream finished package phase (instead of all requested phases), because package creates jar artifact which is needed by downstream projects 2. it changes order of test and package phases (test phases are before package by default), because it allows to schedule downstream dependencies earlier. In other words, it suggests optimistic strategy there instead of original pessimistic As a result, this solution leverages multi-core CPUs way more efficiently. E.g., for our huge Miro monolith application the test execution time (with compiling and running only unit tests) is reduced from 20m to 14m. The parallelization is so good that I even have to use less cores than T1C, like T0.6C because of Amdahl's law effects. The takari-smart-builder, for comparison, gives a very small boost (few percent if all library dependencies are already downloaded to .m2). In the project readme you can find extension adoption for sample maven-surefire project or validate it on your own. The extension is also considered as PoC to change the standard behavior of Maven, which was quite good when it was created 20 years ago. At this moment we did not have multi-core machines, but today this can be revisited to maximize build performance. Also *this is a breaking change* for plugins that rely on the order or phases, e.g. when "test-jar" classified artifact is used as a dependency (which should be avoided IMO 😊). There can be different strategies like opt-in this behavior or introduce a new phase before test. While these disadvantages may look severe, the advantage is a huge potential performance boost. I'm curious about your opinion about it and it would be great if you can try it (you can inspect the code, it's very small - see maven-turbo-builder subdir; other modules are side playground projects which are not directly related to turbo builder extension). On Tue, May 27, 2025 at 5:26 PM Tamás Cservenák <ta...@cservenak.net> wrote: > Hey Sergey, > > Can you tell us more about this "pet project" of yours? > > How is it different from, for example, the takari-smart-builder? > > Thanks > T > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > For additional commands, e-mail: dev-h...@maven.apache.org > >
