与以语言的简易速度对比
本帖最后由 szk820628 于 2020-12-23 18:17 编辑本人测试了易语言 和 火山PC 的速度对比，对比方式如下：
分别进行了最简单的》》》*万次数组加入成员！！！
分别是 100W次数组成员加入，200W次数组成员加入，300W次数组成员加入，400W次数组成员加入，500W次数组成员加入
前期速度基本一致，在400W，500W的数组计算中，火山PC比易语言多用了2秒！！！
可惜啊，测试版本的火山PC惜败。。。。希望这是测试版的原因啊。
吴总封的核心库，整体效率都不是很高，不知道为什么，字节集操作类的效率比易语言还低。但是嵌入的C代码效率就很高。吴总还是可以稍微注重一下效率 我在一开始就提过潜在的效率风险，可惜被忽略了。
这也是没办法，火山的定位就是简单为主而不是效率为主。
火山是把其他语言套一层壳子变成火山类库。但是封装不是简单的翻译，吴总要求封装后的函数必须通俗易懂，让用户只看注释就能学会使用。一个很浅显的道理：越底层的代码效率越高，因为可以针对性优化；相反封装越简单的代码效率越低，因为要考虑普遍情况。
举个简单的例子，假设多选列表有一个函数叫 “取选中行()”。这个函数只需一句话就可以实现需求，非常通俗易懂。但关键在于你不知道他怎么实现的。是每次都遍历一遍？还是有个选中数组来缓存？如果是前者，而你不知道这个知识，那么错误的使用（例如在循环中取选中行）就会非常非常低效。相反，如果是后者实现的，但你不知道，为了提高效率自己又缓存一遍，这就浪费了内存。
因此，封装虽然对新手隐藏了内部实现，但同时也降低了针对性优化的可能性。上面是一个很简单的例子，实际情况复杂的多。例如，我见过很多在 Android 上需要几十上百行代码的功能被封装成一句话。看起来似乎很实用，但实际上很可怕，因为你根本不知道他内部究竟干了什么，所以不知不觉间，程序的整体效率就被拉开了。
事实上，很多看似一句话的代码，里面包含了对象的创建与释放，甚至生命周期管理。这种代码倘若大量在循环中使用，后果是灾难性的。虽然现在设备性能足够折腾，但要是所有应用都像火山这么玩的话，也拖垮了。
所以，真的在意性能，就不应该考虑火山。
路过..... 楼主的代码, 在火山里面, 计次循环() 里面的次数不要每次都计算, 用一个变量保存下来, 否则每次循环都会去执行一次, 当然就慢了 把火山代码 换成
循环(,内容*10000,i)
数组.加入成员(i)
我觉得循环 比计次循环高效 0晨鹤0 发表于 2020-12-23 19:04
我在一开始就提过潜在的效率风险，可惜被忽略了。
这也是没办法，火山的定位就是简单为主而不是效率为主。
...
这么一看，官方描述中的 "具有无与伦比的运行速度" 就更开玩笑一样 xiaoai 发表于 2023-4-27 01:57
这么一看，官方描述中的 "具有无与伦比的运行速度" 就更开玩笑一样
你这个坟，挖的有意思吗，2020年底的帖子，隔了两年半这还回什么啊？ 好像火山计次循环好像会每次循环都会读取一下循环次数的参数，而易语言就不会 xiaoai 发表于 2023-4-27 01:57
这么一看，官方描述中的 "具有无与伦比的运行速度" 就更开玩笑一样
眼光别这么窄,火山效率低是相对c来说的(实际也不算慢,毕竟大点的项目都会封几层),c本身就是最快的了
页:
[1]
2