5月份最新的 Wasm 性能基准测试：
https://csharp-wasm-benchmark.acmion.com/
太长不看：
可得出结论：
现阶段（几年内）没必要用 Wasm 替换所有逻辑，或者将代码全部编译到 Wasm 以求性能提升，即使是用 C 去写所有业务逻辑，也才快 20%。
现版本的 Unity C# 性能可能根本比不过在 JIT 的 V8 加持下的 Cocos Creator。（SIMD 与多线程除外）
所以短期内可以用 wasm 补 js 密集计算和多线程的短板，长期看可以用 wasm 把更多c++能力扩展进引擎
还是很有想象空间的 
嗯，引擎对 wasm 模块的支持应该是在路上，但可能是条漫漫长路。
Lua不是cpp 是c
你这个有没有可能是u3d他估计这样说让你们都不要转成wasm
太慢了吧，就算20%也没什么搞头呀
可以让引擎组放心把引擎原生化，减少工作量
你是指基准测试造假，还是 Unity 人员说假话？
有好的 JIT 虚拟机的语言（C#、Java、JavaScript）在 JIT 之后与静态编译语言的性能差距本来就不太大，所以应该都不是假的。虚拟机语言的问题在内存，GC 等其他方面上。
所谓的 il2cpp 性能也没比 Mono 虚拟机好多少。
那个帖子不是讨论 Wasm 的，我特意又找了出来，原帖在这：https://forum.unity.com/threads/expected-performance-of-new-coreclr-vs-mono-vs-il2cpp.1403353/
太长不看：
结论：
语言的几倍的基准性能差距看起来很多，但在真实项目中就不一定。
如果说原来用 JS，现在全部改用 Wasm，我觉得现在这情况大可不必。
毕竟如果都愿意用 C 去写业务逻辑，追求这 20% 的性能提升了（C WASM 比 JS 快 20%），那怎么能释怀因为要转 WASM 而导致会比原生慢 50% - 200% 的性能差距（WASM C 比 C 要慢 50% - 200%）。
赞成…… 需求的复杂度摆在那，能有这种魔法的话 V8 早就变了
你说的是开启jit以后的比较吗？那ios开不了jit的你怎么说 怎么u3d转完以后的效果在微信小游戏上面的确非常流畅而且发热量比较低 你怎么解答？
unity是微信官方主动帮忙做的优化，cocos就是不是亲儿子 
能发一下unity转微信小游戏以后，非常流畅而且发热量比较低的测试数据或者案例来看看吗？想学习一下
如果真的是开启了jit 只能是调用webview来解析js
最近微信出的文章有说了，就是套了个 webkit 壳。
非高性能模式是跟 Cocos 现在 IOS 差不多，接系统底层去渲染。
高性能模式用 WebKit。
大概是这样，文章懒得找了。
上面数据都是 JIT 的。
不开启 JIT 据称有 5 - 10 倍差距，但没有看到有人做 no JIT 和 WASM 的基准测试，我估计在 IOS 上没有 WASM 快。
你是在暗示 Cocos 在微信小游戏上跑很差吧，但是如何对比的？
我这 U 和 C 的项目都有，U 的全开了高性能模式，但 C 的基本没开，因为都是之前的，不知道这回事，C 的项目开了高性能之后就不发烫了。
你说的如果是真的，我发的数据如果也是真的，那不就证明了我的观点：
没有必要全部转为 WASM，因为你看 Unity WASM C# 转到小游戏都跑得这么好，那我们原生 JIT JS 跑得应该会更好，毕竟基准测试里是打败 WASM C# 的。
补充下，
那么我肯定不会选择所有 JS 换成 WASM，你怎么选择那就看你项目的情况了。
恭喜你，答对了
iOS 的 V8 没有 JIT，想从 wasm 入手大佬有啥建议？
