Re: [PERF] Maven 4 performance on large reactors — 2:45 → 1:18 (parity with Maven 3)

I'll have another look when I get back from PTO.

Le mer. 5 août 2026 à 16:38, Sergey Chernov <[email protected]> a
écrit :

> I've checked the PR changes mentioned in
> https://github.com/apache/maven/issues/12667 and noticed that for
> maven-resolver and maven these are targeted to master branches. Currently,
> the maven-resolver master is 2.0.22-SNAPSHOT, for maven it's 4.1.0-SNAPSHOT
> (not 4.0.0-SNAPSHOT).
> The master branch of maven cannot be easily switched from 2.0.21 to
> 2.0.22-SNAPSHOT as it has breaking changes, so I had to put these changes
> on top of 2.0.21.
> Same for the maven-4.0.x branch, these cannot be cherry-picked as there
> are git conflicts. *I've expected that the provided fixes are targeted to
> 4.0.0, and not postponed to 4.1.0 release.*
> So, I've assembled a mix that was compilable and started the build locally.
>
> The `/path/to/mvn41/bin/mvn validate` (not even package) failed with OOM:
> ```
>
> [ERROR] Java heap space -> [Help 1]
>
> [ERROR] java.lang.OutOfMemoryError: Java heap space
>
> [ERROR] Java heap space -> [Help 1]
> ```
> The heap dump has these top entries, which we discussed recently
> [image: Screenshot 2026-08-05 at 14.23.47.png]
>
> To avoid ambiguity, it would be nice to have a "reference" branch
> aggregating all these changes (for both maven-resolver and maven, install
> and deploy plugins are not critical). Maybe I'm missing something.
>
>
> On Mon, Aug 3, 2026 at 2:01 PM Guillaume Nodet <[email protected]>
> wrote:
>
>> Hi all,
>>
>> I've been profiling Maven 4 RC6 on a large reactor (4,383 modules,
>> diamond-graph, generated with maven-multiproject-generator) as several
>> performance regressions were found during in the vote thread compared to
>> Maven 3. A clean install -DskipTests that takes ~1:15 on Maven 3.9.16 was
>> taking ~2:45 on Maven 4 RC6.
>>
>> After a series of JFR-guided optimizations across 4 repositories, Maven 4
>> now completes the same build in ~1:18 — at parity with Maven 3.
>>
>> Benchmark (Apple M4 Pro, JDK 21):
>>
>> | Configuration | Wall time |
>> |----------------------------|----------------|
>> | Maven 3.9.16 | 1:14 – 1:18 |
>> | Maven 4 RC6 (unpatched) | 2:45 |
>> | + all optimizations | 1:18 |
>>
>> The full analysis (JFR hotspots, root causes, complexity reductions) and
>> all 8 PRs are tracked in:
>> https://github.com/apache/maven/issues/12667
>>
>> The main wins are:
>> 1. Switching the default conflict resolver from classic (O(N²)) to path
>> (O(N)) — single biggest win, 2:45 → 1:45
>> 2. TransitiveDependencyManager optimizations — instance reuse, cons-list
>> parent pointer, varargs elimination
>> 3. Reactor sort O(N² log N) → O(N log N), model building pipeline
>> allocation reduction
>> 4. Install/Deploy plugin O(N²) reactor scans → O(N) with caching
>>
>> All PRs are green and ready for review.
>>
>> Regards,
>> Guillaume
>>
>

-- 
------------------------
Guillaume Nodet