performance optimization

[jerrykingxyz]

Platform

• Macbook Pro M3 Max + 64G + macos 14.3
• Rspack use main branch

Prepare

Enable rspack tracing and JS profiler features by environment. This PR provides a simple implementation, more detail see

• https://github.com/web-infra-dev/rspack/blob/main/packages/rspack-cli/src/cli.ts#L150
• https://rspack.dev/contribute/development/profiling#tracing

For Development

Steps

cd website
TRACE=1 JS_PROFILE=1 npm run start # run with cold start or hot start
echo "111" >> docs/installation.mdx # modify files

Optimization

1. When first cold start the program, the build time is about 11s and the rebuild time is about 180ms. The rebuild time is good enough, let's turn our attention to the cold start time.

• The red block is the hook calling js and waiting for the return, which takes about 4 seconds.
• The yellow block is the make stage, which takes about 6 seconds.
• The green block is the seal stage, which takes about 1 second.

From the js profiler, we can find that the red block is openBrowser blocking the nodejs main thread and causing rspack to get stuck. We should be able to let the openBrowser execute in another thread to avoid this.

2. Let us take a look at hot start after removing openBrowser. The rebuild takes about 2.5s, but 1.8s are consumed in the make stage.

It seems that many files are rebuilt on hot start, from the NormalModule:build parameter we can find that most of them come from the changelog directory.

From the source code, I found that the changelog directory will be regenerated when loadContent is called at https://github.com/facebook/docusaurus/blob/main/website/src/plugins/changelog/index.ts#L159. And a hot start will regenerate it which will make the persistent cache rebuild them since the modification time of those files has been updated.

Here are some solutions I can think of:

• From the trace, the build task in make stage does not have a high degree of concurrency. I guess it is caused by the single-threaded execution on the js side. Maybe we can speed it up through solutions such as thread-loader (ps. The call on the js side will not appear in the trace)
• Hot start adds hash checking for the changelog directory, which can greatly reduce the number of build files during hot start. This feature is currently planned to be supported.
• Even if we solve the hot start problem, users may trigger loadContent to regenerate the changelog when modifying files. At this time, because the changelog is currently under watch, modifiedFiles will be automatically added to the rspack compiler, which may cause the same problem as hot start. I will consider whether it is possible to implement a plugin to intercept modifiedFiles and remove files whose hash has not changed, but this priority will be very low.

Performance

After disable openBrowser and config experiments.cache.snapshot.immutablePaths = [/\/changelog\//]

• cold start: 7.13s
• hot start: 548ms
• rebuild: 180ms

[slorber]

Thanks for the analysis

Indeed we have some execSync() calls in openBrowser() for macOS users. It's legacy code that we ported as-is from Create React App:

https://github.com/facebook/create-react-app/blob/main/packages/react-dev-utils/openBrowser.js#L76

I'll see how to refactor it and use a worker thread for that logic, thanks for letting me know.

---

Will see later for the 2nd problem.

Not that the changelog is a custom plugin on our website, and Docusaurus users do not use it (but there are similar community plugins).

[jerrykingxyz]

• Hot start adds hash checking for the changelog directory, which can greatly reduce the number of build files during hot start. This feature is currently planned to be supported.

web-infra-dev/rspack#10050

[slorber]

Awesome thanks, I also see that the upgrade (facebook#11114) made the dev server startup time much faster 🔥