gnodet commented on PR #1938: URL: https://github.com/apache/maven-resolver/pull/1938#issuecomment-4829329160
_Claude Code on behalf of Guillaume Nodet_ Ran an independent benchmark with the reproducer project (814-module `server_subset`) to validate the changes. ### Results | Configuration | Heap | Time | |---|---|---| | Maven 3.9.16 (baseline) | 768m | 135,724ms (~2m16s) | | 3.10.0-SNAPSHOT (patched, auto) | 768m | 135,082ms (~2m15s) | | Maven 3.9.16 (baseline) | 16g | 135,724ms (~2m16s) | | 3.10.0-SNAPSHOT (patched, auto) | 16g | 135,082ms (~2m15s) | | 3.10.0-SNAPSHOT (patched, `-Daether.conflictResolver.impl=path`) | 16g | 91,435ms (~1m31s) | ### Observations - With `auto` mode (the default), both 3.9.16 and 3.10.0-SNAPSHOT perform identically (~2m15s) regardless of heap size — the auto heuristic falls back to `ClassicConflictResolver`. - When forcing `path` resolver with 16g heap, resolution completes in ~1m31s — **33% faster** than the classic resolver. - The `auto` heuristic does not select `path` even with 16g because the 25% threshold (`available / (4 * 200)` ≈ 21M nodes) is exceeded by the total tree node count. The PR mentions a single module with 7,522 unique nodes producing 1,190,821 tree nodes (158× expansion factor) — across 814 modules, the total easily exceeds the threshold. - This suggests the 25% threshold may be too conservative for projects where the `path` resolver would provide significant speedup. It might be worth considering either raising the threshold or making it configurable. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
