You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@maven.apache.org by Guillaume Nodet <gn...@gmail.com> on 2026/08/03 12:01:22 UTC
[PERF] Maven 4 performance on large reactors — 2:45 → 1:18 (parity with Maven 3)
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
Re: [PERF] Maven 4 performance on large reactors — 2:45 → 1:18 (parity with Maven 3)
Posted by Guillaume Nodet <gn...@apache.org>.
I'll have another look when I get back from PTO.
Le mer. 5 août 2026 à 16:38, Sergey Chernov <se...@gmail.com> 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 <gn...@gmail.com>
> 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
Re: [PERF] Maven 4 performance on large reactors — 2:45 → 1:18 (parity with Maven 3)
Posted by Sergey Chernov <se...@gmail.com>.
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 <gn...@gmail.com>
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
>
Re: [PERF] Maven 4 performance on large reactors — 2:45 → 1:18 (parity with Maven 3)
Posted by Sergey Chernov <se...@gmail.com>.
Nice. Thanks, will try to assemble this locally and will let you know
regarding the build times.
On Mon, Aug 3, 2026 at 2:01 PM Guillaume Nodet <gn...@gmail.com>
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
>