yep, you can try with jprofiler/jetbrains-profiler/something else and see what be the bottleneck. if the project is...open source, we can have a try too...
Xeno Amess <xenoam...@gmail.com> 于2025年5月28日周三 17:09写道： > @Sergey Chernov <serega.mo...@gmail.com> > could you please give a link about the test suites you be using > > Sergey Chernov <serega.mo...@gmail.com> 于2025年5月27日周二 04:56写道： > >> Just tried the 4.0.0-rc-3 comparing with 3.9.9, it's 4x times slower (!) >> on >> a project of ~900 modules (700 of them are jar). >> Maven 3 builds it in 2m57s, while Maven 4 in 11m48s (reproducible, with >> all >> m2 caches). No build cache solutions enabled to compare pure build time. >> Project is nothing special, just java 17 + kotlin 2.1 compilation (no test >> execution). >> It fits into the same heap memory. The CPU cores load is about the same >> (but 4x longer). >> It seems that somewhere there is a huge overhead. >> >> Were there other performance tests at scale? >> >> >> On Mon, May 26, 2025 at 4:48 PM Maarten Mulders <mthmuld...@apache.org> >> wrote: >> >> > Totally agree! I'm not trying to advocate "no more RC's", I'm trying to >> > advocate "last RC should be as close as possible to the final product". >> > And given what has happened between the last RC and today, I don't think >> > we can cut 4.0.0 *today*. The diff is quite large IMO. >> > >> > Thanks, >> > >> > >> > Maarten >> > >> > On May 26th, 2025 at 16:39, Elliotte Rusty Harold wrote: >> > > On Mon, May 26, 2025 at 2:25 PM Maarten Mulders < >> mthmuld...@apache.org> >> > wrote: >> > >> >> > >> That definition makes a lot of sense to me. If we would adhere to >> it, we >> > >> should discipline ourselves after "a" next RC and *not* accept any >> code >> > >> changes *except* for fixing critical uses. >> > > >> > > Be careful not to let the tail wag the dog. if changes are needed, >> > > they're needed. You just need another RC. I would actually prefer that >> > > RCs be identical to the release aside from version number, or even >> > > better that the release candidate binary could simply become the >> > > release, but that's not really how the Maven release process works. >> > > However, critical bug fixes should generate a new RC. Overall I would >> > > prefer much more rigorous versioning. Right now we're pushing RCs with >> > > known unstable APIs, which I would normally consider appropriate for >> > > pre-alpha builds. >> > > >> > >> > >> > --------------------------------------------------------------------- >> > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org >> > For additional commands, e-mail: dev-h...@maven.apache.org >> > >> > >> >
