Rspack performance optimization

Core principle

Optimize from the shape of Rspack's data. Always consider the rough cardinality of internal structures before changing an algorithm:

dependency/export_info > module/exports_info/module_graph_module > chunk > chunk_group > entry/runtime.

The larger the structure, the more dangerous full scans, repeated traversals, broad cloning, eager materialization, and per-item allocation become. Avoid whole-graph or whole-compilation work on high-cardinality structures unless profiling proves it is necessary.

First pass

1. Identify the target feature, file, or compilation stage and the dominant data structures it touches.
2. Estimate whether the hot path scales with dependencies, exports, modules, chunks, chunk groups, entries, or runtimes.
3. Look for repeated CPU work and repeated allocation before designing a larger refactor.
4. Prefer small, measurable changes that preserve observable output.
5. If adding parallelism, respect Rspack's concurrency model: use rayon for CPU-bound synchronous work, use rspack_parallel abstractions for async orchestration, and avoid mixing rayon and tokio pools inside one workflow without a clear boundary.

CPU optimization techniques