- rolldown par plugin
- We now have a example folder to benchmark parallel js plugin using hyperfine. This is for reducing the overhead of initializing worker repeatedly.
- https://github.com/rolldown/rolldown/blob/0e60949b00c1a21168487afe6b49be30a49b02dc/examples/par-plugin/package.json
- Performance gain
- For threejs10x case, let's assume there's a plugin that need transform every module and takes 1ms for each module.
-
Benchmark 1: pnpm rolldown -c ./cases/noop-threejs10x/par-noop.rolldown.config.js Time (mean ± σ): 756.3 ms ± 24.7 ms [User: 5008.5 ms, System: 442.0 ms] Range (min … max): 736.6 ms … 784.1 ms 3 runs Benchmark 2: pnpm rolldown -c ./cases/noop-threejs10x/single-noop.rolldown.config.js Time (mean ± σ): 4.064 s ± 0.007 s [User: 4.325 s, System: 0.872 s] Range (min … max): 4.057 s … 4.070 s 3 runs Summary pnpm rolldown -c ./cases/noop-threejs10x/par-noop.rolldown.config.js ran 5.37 ± 0.18 times faster than pnpm rolldown -c ./cases/noop-threejs10x/single-noop.rolldown.config.js - We could see that parallelism is much better than single-thread. So in theory ,the more time the plugin spends, the higher the gain from parallelization.
-
- For bundling rome-ts using esbuild
-
Benchmark 1: pnpm rolldown -c ./cases/esbuild-rome-ts/par.rolldown.config.js Time (mean ± σ): 654.4 ms ± 21.5 ms [User: 3025.5 ms, System: 617.4 ms] Range (min … max): 632.1 ms … 675.0 ms 3 runs Benchmark 2: pnpm rolldown -c ./cases/esbuild-rome-ts/single.rolldown.config.js Time (mean ± σ): 744.7 ms ± 8.2 ms [User: 960.4 ms, System: 204.1 ms] Range (min … max): 737.3 ms … 753.5 ms 3 runs Benchmark 3: pnpm rolldown -c ./cases/esbuild-rome-ts/single-async.rolldown.config.js Time (mean ± σ): 381.8 ms ± 3.8 ms [User: 421.6 ms, System: 134.9 ms] Range (min … max): 377.5 ms … 384.6 ms 3 runs Summary pnpm rolldown -c ./cases/esbuild-rome-ts/single-async.rolldown.config.js ran 1.71 ± 0.06 times faster than pnpm rolldown -c ./cases/esbuild-rome-ts/par.rolldown.config.js 1.95 ± 0.03 times faster than pnpm rolldown -c ./cases/esbuild-rome-ts/single.rolldown.config.js - We could see that parallelism is slightly better than single-thread but a lot worse than single-thread-async. This is really confusing. In theory,
parallelismshould at least be closed tosingle-thread-async. - I looked into the results and found out
- For the same file, the transform performance difference between esbuild in worker environment and single-async scenario is very large
- For file
../../tmp/bench/rome/src/@romejs/diagnostics/errors.ts- worker: 140ms
- single-async: 4ms
- For file
- For the same file, the transform performance difference between esbuild in worker environment and single-async scenario is very large
- We also hit the same problem in the case bundling rome-ts using babel.
-
Benchmark 1: pnpm rolldown -c ./cases/babel-rome-ts/par-babel.rolldown.config.js Time (mean ± σ): 1.766 s ± 0.043 s [User: 13.783 s, System: 0.860 s] Range (min … max): 1.718 s … 1.800 s 3 runs Benchmark 2: pnpm rolldown -c ./cases/babel-rome-ts/single-babel.rolldown.config.js Time (mean ± σ): 2.613 s ± 0.004 s [User: 4.637 s, System: 0.296 s] Range (min … max): 2.609 s … 2.616 s 3 runs Summary pnpm rolldown -c ./cases/babel-rome-ts/par-babel.rolldown.config.js ran 1.48 ± 0.04 times faster than pnpm rolldown -c ./cases/babel-rome-ts/single-babel.rolldown.config.js
-
-
- For threejs10x case, let's assume there's a plugin that need transform every module and takes 1ms for each module.
- Summary
- Based on the
threejs10x with noop plugincase, parallelism show great potentiality. However, when it comes down real-world cases, the same Js code of plugins run slower in worker environment, which slow down the whole bundling process compared to single-thread bundling.
- Based on the
Last active
May 12, 2024 12:06
-
-
Save hyf0/4f566a1d145a451474e491042d09e4fa to your computer and use it in GitHub Desktop.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment