Skip to content

Instantly share code, notes, and snippets.

@hyf0
Last active May 12, 2024 12:06
Show Gist options
  • Select an option

  • Save hyf0/4f566a1d145a451474e491042d09e4fa to your computer and use it in GitHub Desktop.

Select an option

Save hyf0/4f566a1d145a451474e491042d09e4fa to your computer and use it in GitHub Desktop.
  • 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, parallelism should at least be closed to single-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
        • 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
            
    • Summary
      • Based on the threejs10x with noop plugin case, 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.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment