这样包体就很大了，这也是 unity 这种引擎要上 web 和小游戏平台的天然劣势
如果 Cocos 能把 wasm 这个模块走好，那感觉又是一个优势
怪不得可以使用lua在网页上开发游戏学到的
wasm只适合cpu密集运算的模块,普通游戏逻辑用wasm性能还不如直接用js.
js和wasm之间的交互消耗也很大的
别人不是用wasm写逻辑 是直接编译成wasm
论坛有哥们编译过了 除了多线程 其他都可以移植吧
c++写业务 怎么看也不是个好主意
wasm的性能对比js不会有很大的提升，主要还是可以复用代码；
以前有些功能 cocos需要在C++层和js层都实现，现在只需要在C++层实现，再编译成WASM给h5使用，省了了跨平台开发的工作量
5月份最新的 Wasm 性能基准测试：
https://csharp-wasm-benchmark.acmion.com/
太长不看：
- 理论性能经供参考。
- .Net7 C#，比 JS 快 20%。
- C 编译为 WASM 后，比 JS 快 20%。
- .Net7 C# 编译为 WASM 后，比 JS 慢 1 - 10 倍。
- 提醒：Unity 即使是最新版本，不管是使用的 Mono 或者 il2cpp 都比 .Net7 慢几倍到几十倍，这句话是 Unity 官方人员在其论坛说的，所以以上 C# 的成绩实际上还要大打折扣。
可得出结论：
现阶段（几年内）没必要用 Wasm 替换所有逻辑，或者将代码全部编译到 Wasm 以求性能提升，即使是用 C 去写所有业务逻辑，也才快 20%。
现版本的 Unity C# 性能可能根本比不过在 JIT 的 V8 加持下的 Cocos Creator。（SIMD 与多线程除外）
3赞
所以短期内可以用 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/
太长不看：
- 使用 .Net Core 3.1 与 Mono 相比，性能轻松提升了 2 倍左右。（这个事我记错了，不是和 .Net7 比较，而是和落后 .Net7 好几个大版本的 .Net Core 3.1 比较）
- 事实上，IL2CPP 从未针对性能进行过优化，实际上，IL2CPP 有时与 Mono 一样慢。
- 从很多测试中我们知道 CoreCLR 肯定比 IL2CPP 快。
结论：
语言的几倍的基准性能差距看起来很多，但在真实项目中就不一定。
如果说原来用 JS，现在全部改用 Wasm，我觉得现在这情况大可不必。
毕竟如果都愿意用 C 去写业务逻辑，追求这 20% 的性能提升了（C WASM 比 JS 快 20%），那怎么能释怀因为要转 WASM 而导致会比原生慢 50% - 200% 的性能差距（WASM C 比 C 要慢 50% - 200%）。
赞成…… 需求的复杂度摆在那，能有这种魔法的话 V8 早就变了
你说的是开启jit以后的比较吗？那ios开不了jit的你怎么说 怎么u3d转完以后的效果在微信小游戏上面的确非常流畅而且发热量比较低 你怎么解答？
unity是微信官方主动帮忙做的优化，cocos就是不是亲儿子 