- babel-loader 的主要工作是 AST 解析和遍历。这类工作主要消耗内存,CPU 占用不是最主要的。
- AST 解析这类工作难以并行化。因为编译的各个阶段依赖于前一个阶段的结果,所以难以分到多个子进程中并行执行。
- babel-loader 执行过程中,大部分时间是在waiting AST 解析和 plugin 执行,而不是 compute 密集型工作。如果 proportion 更多的是在 compute,那么它才是更 CPU 密集型。
- 即使使用 HappyPack 或 thread-loader 对 babel-loader 进行加速,性能提升也可能有限。因为其工作过程难以并行,而主要 bottlebeck 并不在 CPU。
所以,总的来说,babel-loader 之所以被认为是非 CPU 密集型,主要原因是:
- 其主要工作是 AST 解析,这类工作主要消耗内存,CPU 并不是 bottlebeck。
- 其工作过程难以有效并行化,不利于利用多核 CPU 提供的计算资源。
- 占用 CPU 的 proportion 相对不是最高的,大部分时间在等待其他工作(AST 解析、plugin 执行)。
- 即使对其进行加速,提升也可能有限,因为 CPU 并不是其 bottlebeck。相比之下,一些图像、视频处理的 loader,其工作过程是计算密集型的,并且易于并行化,这类 loader 更适合称之为 CPU 密集型 loader。使用 thread-loader 等可以充分利用多核 CPU 为这类 loader 提供计算资源,性能提升会更加明显。所以,总结来说,判断一个 loader 是否 CPU 密集型,需要分析其工作过程 - 如果更加倾向于计算和易于并行,那么它更有可能是 CPU 密集型的。如果主要是 AST 解析和遍历,那么就不那么 CPU 密集型
