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

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
>