Slow re-build time when changing JSX structure in React component

[bostondv]

System Info

System:
OS: Linux 5.15 Ubuntu 20.04.6 LTS (Focal Fossa)
CPU: (8) x64 Intel(R) Xeon(R) Platinum 8259CL CPU @ 2.50GHz
Memory: 34.01 GB / 62.01 GB
Container: Yes
Shell: 5.8 - /bin/zsh
Binaries:
Node: 18.19.0 - ~/.nvm/versions/node/v18.19.0/bin/node
Yarn: 1.22.4 - ~/carrot/customers/store/node_modules/.bin/yarn
npm: 10.2.3 - ~/.nvm/versions/node/v18.19.0/bin/npm
Watchman: 20231224.093142.0 - /usr/local/bin/watchman
npmPackages:
@rspack/cli: 0.4.5 => 0.4.5
@rspack/core: 0.4.5 => 0.4.5
@rspack/plugin-react-refresh: 0.4.5 => 0.4.5

Details

We have a very large app that we're experimenting with migrating from webpack to rspack.

We've noticed that in our app the re-build times can vary drastically depending on the type of change made in a file. A particular example that's reproducible is editing JSX structure.

In the below examples, Example 1 consistently takes ~10s to re-build but Example 2 takes only 1-2s.

Example 1: Modify JSX in a React component

function App() {
  return (
    <>
      ++ <h1>foo</h1>
    </>
  )
}

Example 2: Modify content of a JSX tag in a React component.

function App() {
  return (
    <>
      -- <h1>foo</h1>
      ++ <h1>bar</h1>
    </>
  )
}

This is one particular type of change we've noticed and can consistently reproduce but there may be or likely other "kinds" of changes that are slow or fast. Its not clear to me though why one would be slower than the other.

Its a very large app with thousands of files and modules and multiple entry points.

Stats output:

Entrypoint main 21.7 MiB = 72291.webpack_bundle.js 1.64 MiB 50181.webpack_bundle.js 11.9 MiB 28121.webpack_bundle.js 381 KiB 50434.webpack_bundle.js 105 KiB main.webpack_bundle.js 7.7 MiB
Entrypoint test 1.65 MiB = 72291.webpack_bundle.js 1.64 MiB test.webpack_bundle.js 10.3 KiB
runtime modules 29 modules
+ 11813 modules

Through trial and error I've narrowed down a simple config that is reproducible in our codebase with the rspack dev server. Example config repo link provided below, but its not reproducible in this.

To reproduce, the main entrypoint from our large app needs to be in the config (or possibly any very large entry point). Making a file change in only the small test entrypoint (consisting of a single file) is enough to trigger the issue, as long as the large main entry is present in the config.

Really excited to be using rspack ❤️

Reproduce link

https://github.com/bostondv/rspack-perf-demo/blob/main/rspack.config.js

Reproduce Steps

See details above.

[jerrykingxyz]

@bostondv Can you provide a performance trace file?

// https://web-infra-dev.github.io/rspack-dev-guide/profiling/intro.html#chrome
RSPACK_PROFILE=TRACE=layer=chrome npm run dev

// modify the file like example 1 and waiting for rebuild finish
...

// modify the file like example 2 and waiting for rebuild finish
...

// Ctrl + C and find .rspack-profile-${timestamp}/trace.json in the current working directory.

[bostondv]

Thanks @jerrykingxyz

Here's the trace.json (160MB)

[bostondv]

Thanks for pointing out the profiling guide btw. I uploaded the track to https://ui.perfetto.dev/ and can see that in example 1, the bulk of the time is spent in chunk splitting which doesn't happen in example 2 rebuild.

example 1:

example 2:

Any idea why one change causes different behaviour than the other?

[jerrykingxyz]

It seems that example 1 is not using cache and re-splitting chunks, this behavior is not expected, it should only happen when modify imports/exports.
I will try to fix it in the next version of 0.5.x, you can try disable optimization.mergeDuplicateChunks in development mode to make split chunks faster.

[bostondv]

Thank you @jerrykingxyz!

By the way, disabling optimization.mergeDuplicateChunks in development made a huge difference. Reduced rebuilds to about ~5.5s which is very helpful in the meantime.

[jerrykingxyz]

Should been fixed by #5694