RFC: Run JavaScript loaders in worker threads

[h-a-n-a]

PR: #9807

Motivation

Try to use worker_threads to run JavaScript loaders. This adds parallelism to the current JS loader.

User guide

To enable parallelism, set either Rule.use.parallel = true and experiments.parallelLoader = true:

module.exports = {
  module: {
    rules: [
      {
          test: /\.less$/,
          use: [
            {
                loader: "less-loader",
+               parallel: true,
                options: { ... }
             }
          ]
          type: "css"
      }
    ]
  },
  experiments: {
       css: true,
+      parallelLoader: true
  }
}

Detailed design

Worker threads

Unlike thread-loader, rspack uses worker threads to drive loader tasks, using tinypool under the hood. That said, loader options need to be serializable in order to be sent to the worker thread and not all methods are available in LoaderContext. Currently, importModule and most of the methods of _compilation, _compiler, _module are missing.

Loader runner

thread-loader dispatches remaining loaders by default. If I write use: ["thread-loader", "css-loader", "less-loader"], css-loader and less-loader would end up in the worker thread. This is not the same in rspack. You may consider the worker as a loader runner but in worker. If rspack encounters a loader that is set parallel: true, loader runner on the main thread would send the execution state to worker and yield if the next loader is not parallel or it's a rust builtin loader. This chains loaders with parallel enabled automatically, achieving the best performance.

Handling synchronous calls

Worker threads are spawned on demand and, by default, is using the max thread available on the OS. In each worker, a channel is created to pass requests to the main thread for on-demand requesting, such as LoaderContext["getResolve"]. That is to say, each request to the main thread is running asynchronously. This also requires most of the method of LoaderContext to be async. To make it compatible with synchronous loader context calls to the main thread, rspack uses an internal wrapper to wrap an async method into sync, by exposing wait() to each request. For example, addDependency does not resolve until the main thread yield, but getDependencies will wait until all previous adding operation to finish and get the latest dependencies in a synchronous call. This was achieved by putting the thread to sleep and waking it up when it's necessary.

Caveats

• Missing implementations to importModule, _compilation, _compiler and _module methods.
• Options passed to loader should be serializable with regard to the specification.

Benchmark

Building 100 copies of antd.less with css-loader, rspack-plugin-extract-css and less-loader:

# With parallelism enabled on `css-loader` and `less-loader`
hyperfine --runs 5 "rspack build"
Benchmark 1: rspack build
  Time (mean ± σ):      6.972 s ±  0.127 s    [User: 49.337 s, System: 5.876 s]
  Range (min … max):    6.818 s …  7.127 s    5 runs

# Without parallelism
hyperfine --runs 5 "rspack build"
Benchmark 1: rspack build
  Time (mean ± σ):     15.769 s ±  0.058 s    [User: 24.518 s, System: 1.793 s]
  Range (min … max):   15.692 s … 15.836 s    5 runs

Building 100 copies of antd.less with experiments.css and less-loader:

# With parallelism enabled on `less-loader`
hyperfine --runs 5 "rspack build"
Benchmark 1: rspack build
  Time (mean ± σ):      3.960 s ±  0.158 s    [User: 32.401 s, System: 3.055 s]
  Range (min … max):    3.823 s …  4.218 s    5 runs

# Without parallelism enabled on `less-loader`
hyperfine --runs 5 "rspack build"
Benchmark 1: rspack build
  Time (mean ± σ):      8.526 s ±  0.097 s    [User: 14.033 s, System: 1.005 s]
  Range (min … max):    8.425 s …  8.679 s    5 runs

# With `thread-loader`
hyperfine --runs 5 "rspack build"  
Benchmark 1: rspack build
  Time (mean ± σ):      3.814 s ±  0.099 s    [User: 31.751 s, System: 2.394 s]
  Range (min … max):    3.755 s …  3.989 s    5 runs

Benchmark was running on Apple M2 Max, 64G. antd.less is referenced from this.

[hardfist]

what's the behavior when user pass loader options that doesn't follow the specification?

[h-a-n-a]

Doing so will raise a clone failed error. For example, passing a function to the option. This is the original error emitted from MessageChannel. We could improve on this.

ERROR in ./src/less/antd-1.less
  × Module build failed:
  ╰─▶   × DataCloneError: () => { } could not be cloned.
        │     at new DOMException (node:internal/per_context/domexception:53:5)
        │     at WorkerInfo.postTask (file:///Users/bytedance/Projects/rspack/node_modules/.pnpm/[email protected]/node_modules/tinypool/dist/index.js:580:17)
        │     at ThreadPool.runTask (file:///Users/bytedance/Projects/rspack/node_modules/.pnpm/[email protected]/node_modules/tinypool/dist/index.js:900:16)
        │     at Tinypool.run (file:///Users/bytedance/Projects/rspack/node_modules/.pnpm/[email protected]/node_modules/tinypool/dist/index.js:988:38)
        │     at /Users/bytedance/Projects/rspack/packages/rspack/dist/index.js:5376:11
        │     at new Promise (<anonymous>)
        │     at /Users/bytedance/Projects/rspack/packages/rspack/dist/index.js:5297:10
        │     at async isomorphoicRun (/Users/bytedance/Projects/rspack/packages/rspack/dist/index.js:6244:17)
        │     at async runLoaders (/Users/bytedance/Projects/rspack/packages/rspack/dist/index.js:6311:50)
      

[hardfist]

it seems thread-loader is faster than parallelism:true, what's the reason and what's the benefits compared with thread-loader?

[h-a-n-a]

That's true. The overall idea is in the RFC. I don't feel like to use thread-loader as it adds some burden to the options, being compared to rspack's parallel: boolean. The goal for me is to make it as out-of-the-box as possible.

On top of this, thread-loader does not seem to be actively maintained. I found out when I was trying to use the latest css-loader with it and some APIs are missing. Performance-wise, child_process does not support using SharedArrayBuffer to share memory between processes. We may use this to pass Uint8Array between threads.

Anyway, performance can be tuned I believe. It's still experimental though.

[h-a-n-a]

Benchmark seems to vary from time to time. This might be related to the workload of the time. Here's a new result with parallel on:

hyperfine --runs 5 "rspack build"                                                                                                                                                                                            
Benchmark 1: rspack build
  Time (mean ± σ):      3.846 s ±  0.116 s    [User: 31.496 s, System: 3.164 s]
  Range (min … max):    3.729 s …  4.016 s    5 runs

[zhouxinyong]

Does this feature support the sass-loader? I tested it and encountered a DataCloneError.

[h-a-n-a]

Haven't tested sass-loader. Would you attach the error? It's likely related to the loader options.