为什么浏览器上 wasm 的 AES 实现比 js 慢？

不清楚，要不提个 Issus 问问

v8 牛逼？

是不是没用到相应的指令集

现代浏览器 buffer 加持：

Array.from(new Uint8Array(

await crypto.subtle.digest('SHA-1', new Uint8Array(unescape(encodeURIComponent("牛逼")).split("").map(b=>b.charCodeAt(0))))

)).map(b=>('0'+b.toString(16)).substr(-2)).join('')

搞错了，AES 是用 crypto.subtle.encrypt 😂 支持 AES-CTR 、AES-CBC 、AES-GCM

@warcraft1236 应该都是纯软件实现吧

从对比图里我没看出来 wasm 慢了，明明 wasm 的计算时间比 js 要短，怎么就变成慢了？

@Wincer 你看 aes 那里阿

@Jwyt #8 哦不好意思，是我看漏了

总是有人以为 JS 很慢...其实 JS 基本上算是脚本(或者解释型, 按照大部分人的定义来说)里面最快的了
不过这种对比吧, 你也不知道他具体实现是怎样的, 也许双方抠抠细节都还能有较大提升

官方制图是不是搞错了，我用 github 上的测评页面运行了一下，wasm 明显比 js 快了很多。

@tool2d 多运行几次试试，是不是还没触发 jit 优化？

@inhzus #2
FireFox 和 V8 有什么关系？

这图不是循环 10 次，wasm 用时更短的意思？

我这后者快点，手机上跑的

想不到看到了在 V2EX 上看到了自己的东西 :)

这个 benchmark 出来结果后，我们也内部讨论过(甚至对 aes 有针对性优化，但是效果不明显)，跟大家的看法差不多：
1 、js+V8 没那么拉垮，JIT 应该还是很明显的
2 、aes 的计算量不大(从运行时间也能看的出来)，在这种情况下，wasm 由于内存拷贝(胶水代码所负责)所附带的性能影响较明显

由于相关调试工具的缺失，这块没有深究下去，大家有兴趣也可以讨论下

另外，在测试中还发现了一些有意思的地方：chrome 在开启 performance record 后，性能表现较好，结果也比较稳定，猜测是 chrome 在 performance record 时会对内存及时进行清理。

@tool2d @des 我们的 benchmark 是有 warm-up 的，已经考虑了 jit 等优化，benchmark 代码开源在 github ；列出的测试结果是在一般的硬件条件下获得的，大家硬件不同，不过一般来说都会比我们所列的测试结果要好


最后，虽然有点王婆卖瓜的不好意思，但是还是介绍一下 crypto-js-wasm：相比于原来的 crypto-js ，除了引入 wasm 外，还用 ES 进行了重写、加入了 rollup 打包和 jest 测试，还增加了 ts 的支持。后续还考虑增加更多算法(对标 openssl)、加入 simd 、适配其他 runtime(比如 RN)

希望大家可以尝试用用 crypto-js-wasm ，当然 issue 、pr 就更欢迎了