各位CCC的开发兄弟们，随着Creator1.5的发布，这个引擎的功能已经非常完善了。
不知道接下来的大版本会有什么样的改进，个人认为在功能方面应该已经差不多了，是该留一些的时间来做一些底层的改进了。
因为我们的项目主要是以手游为主，所以对原生版本的期望更大，真心希望你们花一些时间把原生版的性能给提上来。像之前发过的一个贴子：http://forum.cocos.com/t/native-web/46686
原生版创建结点的代价比Web版的大很多，不单单是贴子里分析的两处代码问题，就算我把两处问题解决掉，仍然比Web版慢3到4倍。这或许可以归结为原生版的JS引擎慢，但也可能是JSB的绑定方式消耗了很多性能，更可能是Cocos2dx本身的问题。
还有文字，我专门看了cocos2dx的代码，里面的实现方式是用512大小的纹理来缓存各个字符，这样的实现方式性能应该是挺好的，但他的效率就是比Web版的差。
所有这些基础问题，希望你们专门花一些时间好好分析一下，如果需要我提供一些Demo，我愿意弄一些给你们，这样你们可以看到一个真正的游戏项目涉及到的性能问题。
1.6 版本都是冲着性能优化和稳定性去的。
哎 说出心声 原生版本效率太低了 简直了
我在昨天微信推送的版本发布文章里面写了
下个版本 Creator v1.6 重点功能预告
1、Bug修复。社区里很多人提出了来一个『0 Feature』的版本，我觉得这个建议蛮好，v1.6的主要基调就是修bug，以及提高性能。
2、文档更新。虽然同事们一直在努力更新文档，但是我看了论坛反馈之后，自己再去看这些中文文档，发现同事们还是写得太跳跃了，对于引擎人员很多地方觉得显而易见就一笔带过，实际上很容易给刚入门的新手带来困惑。
3、原生平台性能优化，升级SpiderMonkey版本 —— 目前用的是三年前的老版本了。同时，这项工作会重构JSB API的绑定层面，目前的进度是，我们已经让一个JavaScript - C++绑定层的设计不仅可以用在Spider Monkey上，也可以用在iOS的JavaScriptCore、Android的v8、微软的ChakraCore等不同JS引擎上，这可以最终达到减小包体积、提高JS引擎性能的目的。我非常希望这项功能可以赶上v1.6版本的发布时间点。这项工作实际上已经启动了几周了，但还处于比较初期的状态。
赞，这是我听到最高兴的消息了，加油了引擎。
还有一点希望能改进下，现在修改脚本之后，creator重新编译要半分钟，能不能之编译修改过的脚本，提升下编译的速度。
赞，就是需要一个稳定版本。
能不能像vs2015这些编译器一样，可以在编译前、编译完、构建前、构建完执行自定义脚本（构建完成后自动执行自己定义的热更新文件生成脚本，免得忘记了）。
毕竟是3年前的SpiderMonkey版本，不能对3年前的东西要求太多。
不过这次改进也会带来不小的代价，因为JSB API变了，所以原先用JSB开发的项目，如果升级上来，就都需要都需要重新绑定一次C++库到JS
youyou老师总是这么给力
希望能提高CANVAS模式下的运行效率 现在还有很多安卓机上的浏览器没有Opengl
这点代价不算什么 我能接受 性能尽管往死里优化
这两天看到Egret发布了5的版本，说支持将JS编译成webassembly，这带来的性能提升相当巨大。
虽然引擎开发的兄弟们都很辛苦，但追求极致的性能永远是游戏界不变的主题：），有了这项黑科技， 可以媲美原生的开发性能，有点太诱人了。
Creator这边有这方面的计划吗。
13年开始用cocos，那时候还只有cocosbuilder，后来又cocosstudio，最初还只有win班，然后又了cocosIDE，相比于前几个，现在creator确实先进很多，真心希望能把creator好好打磨一下，加油。
目前，据我所知的，我们团队正在开发的，是creator最重度的游戏了，特别期待优化的性能和编译速度~~
WebAssembly 的预研我们早就在做了，这个技术的使用对我们来说并不是什么门槛，只是目前支持的范围还不够广，所以我们的计划没有那么激进。目前的计划会以引擎整体为基准来考量，包括编辑器，工作流，底层引擎，原生支持。短期的发展方向和侧重和别家不太一样，长期来看，会殊途同归，就好像 Creator 学习 Unity 引领了 Web 引擎的组件化潮流 
。
WebAssembly 技术对于 Web 的确是一大利好，不过它的问题目前还很多，比如目前无法调试，支持的浏览器有限，难以扩展。这项技术本质上来说，是用原生技术来替代 Web 技术，实际计划上，我们会将部分原生模块逐步从原生编译到 WebAssembly 模块，不过这不是我们近一个月的重点，我们还是会先集中将 JSB 引擎的性能提升上去。
是的是的 不要听他们乱忽悠，目前来说只是个噱头。优化好JSB性能 才是目前广大客户的需求
对的，非常赞同，先把JSB的性能提升上去，Creator相对于Egret能更好的支持Web和Native，这是一个很大的优势。
对于WASM，我的观点也是一样的，我并不希望用它来完全代替JS的开发，只是希望能通过它，将很多优秀的原生库搬给JS用。像最近在做协议压缩，使用Lz4或Snappy，服务器由于是Lua，和C/C++集成得非常好，基本上优秀的原生库都可以拿来用。JS这边就麻烦得多，要兼顾Web和Native就尽量想找纯JS实现的库，但那个性能真的非常的慢。
按计划一步步来吧：）