sonofmagic
commented
4 months ago 去除编写 swc 插件目标 (2024/03/13)
我把编写 swc 插件这个目标给去除了，原因是我基于 @ast-grep/napi 实现了一个 beta 版本，然后发布了。
结果跑 e2e 测试的时候，发现比原先的 babel 还要慢？？？！！！
然后，为了找到原因，我去看了 ast-grep 的源代码，并跑了一下它自带的 bench 来做基准测试
测试脚本不是我写的，是直接跑 https://github.com/ast-grep/ast-grep/tree/main/benches 这里的测试脚本
测试设均为 Mac Book Pro m1 ， 测试分为对 同步 和 异步 API 进行测试，
测试解析的 js 文件对象为 超小,小, 中等,巨大 四种体积，下方结果的 ops 数据越大越快。
测试结果如下:
同步API测试结果（点击查看）
```bash
Running "parseSyncBench: Parse One Line" suite...
Progress: 100%
ast-grep sync parse:
50 164 ops/s, ±5.38% | 50.44% slower
babel sync parse:
3 642 ops/s, ±3.17% | slowest, 96.4% slower
oxc sync parse:
39 646 ops/s, ±0.61% | 60.83% slower
swc sync parse:
11 111 ops/s, ±0.64% | 89.02% slower
TypeScript sync parse:
101 218 ops/s, ±2.51% | fastest
Finished 5 cases!
Fastest: TypeScript sync parse
Slowest: babel sync parse
Running "parseSyncBench: Parse Small File" suite...
Progress: 100%
ast-grep sync parse:
3 516 ops/s, ±0.66% | 58.09% slower
babel sync parse:
2 669 ops/s, ±4.13% | 68.18% slower
oxc sync parse:
3 502 ops/s, ±2.77% | 58.25% slower
swc sync parse:
2 004 ops/s, ±0.75% | slowest, 76.11% slower
TypeScript sync parse:
8 389 ops/s, ±2.09% | fastest
Finished 5 cases!
Fastest: TypeScript sync parse
Slowest: swc sync parse
Running "parseSyncBench: Parse Medium File" suite...
Progress: 100%
ast-grep sync parse:
200 ops/s, ±0.79% | 48.05% slower
babel sync parse:
385 ops/s, ±3.51% | fastest
oxc sync parse:
204 ops/s, ±0.92% | 47.01% slower
swc sync parse:
137 ops/s, ±1.43% | slowest, 64.42% slower
TypeScript sync parse:
340 ops/s, ±3.45% | 11.69% slower
Finished 5 cases!
Fastest: babel sync parse
Slowest: swc sync parse
Running "parseSyncBench: Parse Huge File" suite...
Progress: 100%
ast-grep sync parse:
1.1 ops/s, ±1.24% | 42.11% slower
babel sync parse:
1.5 ops/s, ±4.69% | 21.05% slower
oxc sync parse:
1.2 ops/s, ±1.59% | 36.84% slower
swc sync parse:
0.8 ops/s, ±2.14% | slowest, 57.89% slower
TypeScript sync parse:
1.9 ops/s, ±3.52% | fastest
Finished 5 cases!
Fastest: TypeScript sync parse
Slowest: swc sync parse
```
异步API测试结果（点击查看）
```bash
Running "parseAsyncBench: Parse One Line" suite...
Progress: 100%
ast-grep async parse:
21 930 ops/s, ±5.93% | 77.25% slower
babel async parse:
1 087 ops/s, ±1.97% | slowest, 98.87% slower
oxc async parse:
19 234 ops/s, ±4.30% | 80.05% slower
swc async parse:
9 414 ops/s, ±1.59% | 90.23% slower
TypeScript parse(not async):
96 388 ops/s, ±1.69% | fastest
Finished 5 cases!
Fastest: TypeScript parse(not async)
Slowest: babel async parse
Running "parseAsyncBench: Parse Small File" suite...
Progress: 100%
ast-grep async parse:
4 749 ops/s, ±22.01% | 42.87% slower
babel async parse:
921 ops/s, ±4.62% | slowest, 88.92% slower
oxc async parse:
3 796 ops/s, ±0.56% | 54.34% slower
swc async parse:
2 529 ops/s, ±2.46% | 69.58% slower
TypeScript parse(not async):
8 313 ops/s, ±1.49% | fastest
Finished 5 cases!
Fastest: TypeScript parse(not async)
Slowest: babel async parse
Running "parseAsyncBench: Parse Medium File" suite...
Progress: 100%
ast-grep async parse:
475 ops/s, ±4.92% | fastest
babel async parse:
219 ops/s, ±40.10% | 53.89% slower
oxc async parse:
246 ops/s, ±0.76% | 48.21% slower
swc async parse:
190 ops/s, ±0.34% | slowest, 60% slower
TypeScript parse(not async):
310 ops/s, ±5.35% | 34.74% slower
Finished 5 cases!
Fastest: ast-grep async parse
Slowest: swc async parse
Running "parseAsyncBench: Parse Huge File" suite...
Progress: 100%
ast-grep async parse:
1.8 ops/s, ±64.07% | fastest
babel async parse:
1.2 ops/s, ±8.97% | 33.33% slower
oxc async parse:
1.5 ops/s, ±11.31% | 16.67% slower
swc async parse:
1 ops/s, ±3.43% | slowest, 44.44% slower
TypeScript parse(not async):
1.6 ops/s, ±9.93% | 11.11% slower
Finished 5 cases!
Fastest: ast-grep async parse
Slowest: swc async parse
```
结论
用 rust 写的工具，异步的性能要比同步好一点，同时处理的文件越小，性能越快。
但是，小文件的解析本身也不怎么耗时间呀？
而且，看到 swc 这样的测试结果，我不由得对 rust 是前端新基建的说法产生了怀疑。
当然，如果你测试的结果有所不同，或者是有其他的异议，欢迎和我进行交流。
转眼这个项目已经 2 年多了，算是我这么多开源里面，目前唯一火起来，有人用的吧（笑～），秉着不抛弃不放弃用户的原则，和目前所存在的问题，我大概制定了一下未来的技术规划以及立下一个 Flag:
- 编写 swc 插件，使用 swc 来替换掉 babel ，因为 babel 在项目大的时候，性能比较低，可能一个大js文件 parse 就要 200-300ms，这个是缓存也无法解决的问题，所以需要对 js 方面的转义，以及相关的包 “锈化”(具体原因见下)ast-grep(rust编写) 支持, 通过基准测试，在项目中，平均速度大约比babel快2倍左右 (3.1.0 版本支持 2024/03/23) https://github.com/sonofmagic/weapp-tailwindcss/pull/28310个贡献者(4/10)4篇文章给weapp-tailwindcss(2/4)used by开源项目超过1k，(目前2年不到400，因为小程序开源项目本来就少)tailwindcss@4.x, 这个是新的rust引擎taro rn，这个也是很多用户都在提的 https://github.com/sonofmagic/weapp-tailwindcss/issues/262目前想到的就这些，希望我们能达成目标！
贡献者们快来啊，有啥不懂的，我都事无巨细的解释给你们听！
贡献指南: https://weapp-tw.icebreaker.top/docs/how-to-contribute