rspack-sources future optimization prospects

[SyMind]

This topic is intended to discuss the possible future enhancement paths for rspack-sources.

Not suitable for concurrency

After assessment, it is deemed inappropriate for rspack-sources to adopt concurrent processing at the current stage:

1. The data structure currently used by rspack-sources is a bottom-up recursive tree model. If the concept of concurrency is introduced, it would require the interruption of the bubbling process at certain nodes in the tree structure and then resume it. Our test results show that the cost of such an interrupt-resume mechanism outweighs the performance benefits that concurrency might bring.

2. In the SourceMapDevToolPlugin component of rspack, we have already achieved the calculation of source maps through concurrent processing on a chunk-by-chunk basis, and this parallel strategy has proven to be adequate for the needs of actual projects. Furthermore, the number of concurrent operations has exceeded the number of CPU cores, meaning that there is no need to further increase the complexity of concurrency.

3. Maybe we can try SIMD

Possible Optimization Avenues to Explore

Looking forward, rspack-sources may consider optimization from the following two directions:

1. The current project uses the String type (based on utf8 encoding) to store source code strings, leading to significant performance overhead for substring splitting. Exploring more efficient data structures or storage methods to optimize this process is worth considering.

2. By adopting the index source map approach, we anticipate a significant reduction in computational resource consumption during the concatenation of source maps when finalSource is true.