从包版本 0.19.0 开始,这个插件的构建缓存似乎使性能变差而不是改进它。
在我公司升级构建脚本以使用所有内容的最新包版本时,我注意到了这一点; 包括ezolenko/rollup-plugin-typescript2
从版本 0.12.x 到 0.19.2 的更新。 这将捆绑时间增加了大约 1 倍。 2x(从每捆约 3 秒到 6-8 秒)。
我想我会和你分享我的简短调查。 我设置了一个小基准(参见stakx/rollup-plugin-typescript2-benchmark
)来演示这一点。 不可否认,它不是一个超级准确的基准,但我认为它仍然表明将clean
选项设置为false
似乎会对捆绑时间产生负面影响(而不是像人们期望的那样改进它)准备使用的缓存)。
我将重现我在下面进行的测量; 有关实际的基准代码,请参阅链接的 repo。
包版本 | 运行 | clean: true
[毫秒] | clean: false
[毫秒] | clean: false
÷ clean: true
[%]
:-:|:-:|--:|--:|--:
0.15.0 | 1 | 第836话第670话
| | 2 | 840 | 第638话
| | 3 | 第884话第574话
| | 平均 | 第853话第627话 74%
0.16.0 | 1 | 第841话第576话
| | 2 | 第816话 607 |
| | 3 | 第834话第581话
| | 平均 | 830 | 第588话 71%
0.17.0 | 1 | 第861话 582
| | 2 | 第839话 603
| | 3 | 第835话 594
| | 平均 | 第845话第593话 70%
0.18.0 | 1 | 第1147章 998
| | 2 | 第1192章 882
| | 3 | 1207 | 882
| | 平均 | 第1182章 921 | 78%
0.18.1 | 1 | 第815话 617
| | 2 | 第837话 590
| | 3 | 第823话 590
| | 平均 | 第825话第599话 73%
0.19.0 | 1 | 第828话 896
| | 2 | 803 | 897
| | 3 | 第836话 901
| | 平均 | 第822话第898话 109%
0.19.1 | 1 | 850 | 913
| | 2 | 第825话 888
| | 3 | 第799话 881
| | 平均 | 第825话第894话 108%
0.19.2 | 1 | 1020* | 888
| | 2 | 第816话 902
| | 3 | 第826话 890
| | 平均 | 第887话第893话 101%
请注意,在 0.18.1 之前,填充缓存 ( clean: false
) 如何导致更快的捆绑时间(大约clean: false
70%)。 从 0.19.0 开始, clean: false
实际上会增加捆绑时间大约。 10%。 (还要注意标有 * 的异常值,这使得 0.19.2 看起来比实际表现更好。)
这种缓存减速非常遗憾,特别是因为clean: false
目前是默认的.
(PS:我想明确一点,我并不是说clean: false
本身就足以恶化这个插件的性能。我只是注意到了这一点并觉得很好奇,可能值得研究更多密切。)
谢谢,我希望下周某个时候看一下。 一般来说,我希望clean: true
比第一次使用缓存运行快一点,并且比使用缓存的第二次运行慢得多。 看起来您正在比较干净系统上的首次运行?
另一个要控制的变量是打字稿和汇总版本。
有一个修复,忘记是哪个版本了,当使用clean: true
时完全删除了缓存创建,因此在构建期间完成的工作更少。
顺便说一句,这可能意味着构建执行干净结帐的机器(每个健全的非 CI 部署配置都应该这样做)可能会通过禁用缓存来提高一些速度。
看起来您正在比较干净系统上的首次运行?
我的基准测试执行两次:
第一个在使用rimraf
手动擦除缓存后运行。 这次运行不会被测量,它只是为了构建一个新的缓存。
第二次运行(如果clean: false
可以利用新缓存)是被测量的一次。
好的,我看到了。 看起来在 19.2 缓存总是因为某种原因丢失。
好的,在 master 中修复。 不过,我仍然需要检查修复程序如何影响手表模式。
现在在 npm 上的 0.19.3
惊人的! 感谢您如此迅速地处理此事。 很高兴看到一个项目得到如此好的维护。 :+1:
最有用的评论
现在在 npm 上的 0.19.3