refactor(split-chunks): speed up module group processing

[LingyuCoder]

Summary

This PR focuses on reducing splitChunks overhead in rspack_plugin_split_chunks, especially around module group preparation, winner selection, and repeated post-processing.

Key changes:

• Narrow invalidation after a winner is chosen by building an AffectedModuleGroupIndex, so we only revisit module groups that actually share both modules and chunks with the winner.
• Replace repeated linear best-group scans with a BinaryHeap-based ModuleGroupQueue plus lazy version invalidation, while keeping deterministic tie-breaking.
• Add a parallel fast path for static cache groups in prepare_module_group_map when chunks / test / name / layer do not require async or dynamic evaluation, avoiding the previous shared DashMap write contention.
• Reduce minSize-path clone overhead by returning borrowed SplitChunkSizes and collecting source-type modules into Vec<ModuleIdentifier> instead of cloning full sets.
• Keep deterministic ordering and fix review issues by:
  • comparing size reduction with f64::total_cmp
  • only removing queue versions after a successful swap_remove
  • requiring live keys when refreshing heap entries
  • using a stable tie-break in ordered_module_identifiers

Additional plumbing:

• add has_custom_layer_filter to detect whether the static fast path is safe
• align the same borrowed-size behavior in rspack_plugin_esm_library

Local validation:

• cargo fmt --all --check
• cargo clippy -p rspack_plugin_split_chunks -- -D warnings

Related links

• PR: refactor(split-chunks): speed up module group processing #13322
• Ecosystem benchmark / review discussion is in the PR thread

Checklist

• Tests updated (or not required).
• Documentation updated (or not required).

[Copilot]

Pull request overview

Refactors split-chunks module group processing to improve performance by reducing invalidation scope and optimizing module-group winner selection.

Changes:

• Introduces a reverse index to narrow invalidation to only affected module groups.
• Replaces linear “best module group” selection with a BinaryHeap + lazy invalidation queue.
• Avoids repeated SplitChunkSizes cloning by returning references in the minSize validation path.

Reviewed changes

Copilot reviewed 5 out of 5 changed files in this pull request and generated 4 comments.

Show a summary per file

File	Description
crates/rspack_plugin_split_chunks/src/plugin/module_group.rs	Adds reverse index + heap-based queue; updates invalidation/refresh workflow.
crates/rspack_plugin_split_chunks/src/plugin/mod.rs	Switches main loop to heap-based selection and passes new validation context/index.
crates/rspack_plugin_split_chunks/src/plugin/min_size.rs	Updates container trait to return &SplitChunkSizes and avoids cloning in validation.
crates/rspack_plugin_split_chunks/src/module_group.rs	Adjusts APIs (collect_source_types_modules, get_sizes) and adds ordered module identifier helper.
crates/rspack_plugin_esm_library/src/split_chunks.rs	Aligns get_sizes behavior with reference-return refactor.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[github-actions]

Rsdoctor Bundle Diff Analysis

⚠️ Note: The latest commit (5f17956633) does not have baseline artifacts. Using commit 8787ed98aa for baseline comparison instead. If this seems incorrect, please wait a few minutes and try rerunning the workflow.

Found 5 projects in monorepo, 0 projects with changes.

📊 Quick Summary

Project	Total Size	Change
react-10k	5.7 MB	0
react-1k	826.3 KB	0
react-5k	2.7 MB	0
rome	984.2 KB	0
ui-components	2.3 MB	0

Generated by Rsdoctor GitHub Action

[github-actions]

📦 Binary Size-limit

Comparing 3def2b0 to chore(deps): bump @rslib/core to 0.20.2 (#13525) by Timeless0911

❌ Size increased by 14.63KB from 49.04MB to 49.06MB (⬆️0.03%)

[codspeed-hq]

Merging this PR will degrade performance by 3.93%

🎉 Hooray! codspeed-rust just leveled up to 4.4.1!

A heads-up, this is a breaking change and it might affect your current performance baseline a bit. But here's the exciting part - it's packed with new, cool features and promises improved result stability 🥳!
Curious about what's new? Visit our releases page to delve into all the awesome details about this new version.

❌ 1 regressed benchmark
✅ 15 untouched benchmarks
⏩ 19 skipped benchmarks¹

⚠️ Please fix the performance issues or acknowledge them on CodSpeed.

Performance Changes

	Mode	Benchmark	BASE	HEAD	Efficiency
❌	Simulation	rust@split_chunks	9.1 ms	9.4 ms	-3.93%

---

_{Comparing codex/split-chunks-affected-index (3def2b0) with main (5f17956)}

Footnotes

1. 19 benchmarks were skipped, so the baseline results were used instead. If they were deleted from the codebase, click here and archive them to remove them from the performance reports. ↩

[github-actions]

📝 Benchmark detail: Open

task failure

[LingyuCoder]

@codspeed explain the perf diff

[codspeed-hq]

@codspeed explain the perf diff

Here's my analysis of the performance report for this PR:

---

Performance Summary

Benchmark	Base → Head	Change	Verdict
rust@split_chunks	9.1 ms → 8.3 ms	+9.07% ⚡	Expected improvement — this is the target of the PR
bundle@basic-react-development	343.1 ms → 347.3 ms	-1.23% ❌	Likely noise (see below)
rust@create_module_hashes	21.8 ms → 22.1 ms	-1.47% ❌	Unrelated code path (see below)
rust@concatenate_module_code_generation	143.4 ms → 145.5 ms	-1.49% ❌	Unrelated code path (see below)

The improvement: rust@split_chunks (+9.07%)

This is the benchmark directly targeted by the PR and it shows a clear, significant win. The ~0.8 ms reduction (9.1 ms → 8.3 ms) is consistent with the optimizations described: narrowing invalidation via AffectedModuleGroupIndex, the BinaryHeap-based queue, and the parallel static cache group fast path.

The regressions: likely measurement noise

The three flagged regressions are all small in magnitude (1.2–1.5%) and occur in code paths unrelated to split chunks:

• rust@create_module_hashes (-1.47%, ~0.3 ms delta): The flamegraph shows time is dominated by module_update_hash, ChunkGraph::get_module_graph_hash, exports info prefetching, and xxhash hashing — none of which are touched by this PR. The top self-time functions are malloc, free, and hashbrown table operations, which are sensitive to memory layout changes from recompilation.

• rust@concatenate_module_code_generation (-1.49%): Similarly unrelated — this benchmark exercises concatenated module code generation, which has no overlap with split chunks logic.

• bundle@basic-react-development (-1.23%, ~4 ms on a 343 ms benchmark): While split_chunks is part of the full bundle pipeline, the split_chunks stage itself got faster. The small regression in the end-to-end bundle benchmark at this magnitude is within typical measurement variance.

Why unrelated benchmarks can show small swings

In simulation mode (instruction-level measurement via Valgrind), even changes that don't touch a benchmark's hot path can cause small fluctuations (~1–2%) due to:

• Binary layout shifts: Adding/modifying code in the crate changes function placement, affecting instruction cache behavior and branch prediction metadata.
• Inlining decisions: The compiler may make slightly different inlining choices when surrounding code changes, affecting instruction counts in unrelated functions.

Conclusion

The +9.07% improvement on split_chunks is the real signal here and validates the PR's optimizations. The three regressions are small, occur in unrelated code paths, and are consistent with typical measurement noise from binary layout changes. They should not block this PR.

Summary

• Warming up the performance wizard...
• Analyzing performance report — Completed flamegraph and comparison analysis
• Handling comment — Comment handling finished successfully