高手讨论→RM里你们在乎程序效率吗？

九夜神尊

忘了是哪位高手说的，RM的内部结构不是最优的。

那时候我还不懂，只是记住并知道这么回事。

在我写自己的系统的时候，写到了人物属性的取得。
这个模块我想大家都很熟悉，防御 =武器防御+帽子防御+盾防御+衣服防御。

但是，每次获取防御力都要经过这么一次运算，然而结果却大部分相同。显然程序效率低很多（当今的电脑似乎可以忽略）。

不过我想，RM作者最初不会没考虑到，而是为了让使用者容易上手。如果把每个属性保存成一个变量，每次读取的时候，直接
调用，在换装备的时候，再改属性。虽然效率会高很多，但是新手却很难上手。

不晓得各位高手对程序效率怎么看待的，就我本人而言，一个程序在我能力下，有优化的空间，我就觉得这程序没完成。

不过像我说的，属性的获取我倒是决定不优化，因为优化后会与现有大部分脚本脱节。

以下是我的一个感叹

血条，每次都要描绘么？

不，只需要在HP 或MAX_HP有改变的时候重新描绘

每次改变都要重新描绘么？

不，血多了就描绘一段红色把黑条盖住，血少了就描绘一条黑色把红条盖住

然而最后要吐自己的是：在乎效率就别用RUBY

moy

别同?是指别用麽......

紫苏

程序效率是一个大话题，够写好几本书了（编译原理中的编译器优化理论），不过概括地说，常用的手段有：

降低算法复杂度
包括优化整体算法结构，使用合适的、高效的数据结构，给耗时的运算添加合适的分歧跳转（即主楼提到的“只需要在HP 或MAX_HP有改变的时候重新描绘”）等

最小化冗余
见 http://rpg.blue/thread-154785-1-2.html 11楼

紧密分配相关性强的代码和数据的位置
这提高了空间访问局部性，也就提高了 Cache 和内存操作效率

发挥内存阶层的长处
效率上，目前主流的配置大概是：CPU 寄存器 > CPU Cache > 闪存（USB 内存） > RAM（主内存） > HDD（硬盘） > 磁带 > ……
效率越高的存储方式在内存阶层中越处于上层，要尽量使用上层的存储，比如 RM 的 Cache 就是避免了频繁进行硬盘读写操作，而把位图的存储带到了相对高效的 RAM 内存中（因为 RAM 在 HDD 的上层）

简化语言相关、机器相关的运算
有些运算方式在有些语言或机器上效率低于另一些运算方式——
语言相关：如在头部检测条件的循环效率效率低于在尾部检测条件的循环
机器相关：如加减法效率低于乘除法、浮点数效率低于定点数

以上，优化 in a nut shell

死伤殆尽

RM这系列软件，乃至整个tkool系列，从一开始就不是作为普通的游戏制作软件而开发的
这系列的特色和优势就在于使用简单，容易上手，只需要掌握最基础的操作就能轻松地制作出自己想要的作品
我认为在这个前提下，谈论效率是毫无意义的

熊的选民

必要的优化还是要的，比如至少不能每桢都refresh一次，尽量避免遍历事件列表

六祈

回复 九夜神尊 的帖子

小九注意到脚本的效率是很可喜的。

话说愚者第一次注意到这点是因为【后知后觉】前辈的点评。http://rpg.blue/forum.php?mod=vi ... p;page=1#pid1456488

为此愚者重新写了那段改变选项颜色的代码【没能完善，后来坑掉了】

目前的经验就是：对于bitmap类的draw_xxx方法【其它涉及到bitmap位图类的方法也是】，代价是很大的，还是应该在非draw不可的场合再draw。其它类似一些数据计算或者数据计算之类的迭代，时间效率还是非常不错的。

另外对小九的一些想法有一些不同意见：

【防御 =武器防御+帽子防御+盾防御+衣服防御。但是，每次获取防御力都要经过这么一次运算，然而结果却大部分相同。显然程序效率低很多】

如果用一个新变量来取值的话：

首先，增加内存开销，空间效率下降【虽然也是忽略不计】

其次，每次更新【武器防御】或【任意护具防御】的时候，都要顺带更新这个【防御】，额外的计算量降低时间效率【依然忽略不计】

最后最重点的是：用【查询方法替换冗余变量】可以使程序结构更易懂【有点拗口么。。试想一下，如果一个类有20个实例变量和它如果只有10个实例变量，哪种情况更易读】

禾西

ruby 的效率雖然多有咎病，但問題其實不算大嚴重。如果沒有良好習慣的話，就算是匯編也救不了你。
1不要用大數值運算，2不要重複讀取大量數據，3不要不要過多刷新bitmap或使用諸如rand，GC.start等高代價方法。
這樣寫出來的程序效率其實還是蠻高的。
底層語句不得力不是借口，我們選擇ruby是因為他方便易用。而方便易用其實和效率并不衝突，在力所能及的位置對程序進行優化是必不可少的工序。君不見提問區老是出現：為甚麼我的遊戲做出來會卡？而其他人的不會？——這就看出水平的高低了。

柳柳

实践证明，RM的效率还行。之前为了游戏的帧率，用了个微秒测试器仔细测过游戏里所有主要函数在大多数情况下的运行时间。即时以我优化得最差的时候，基本也是逻辑占10%时间左右，渲染占90%左右。优化好一些逻辑占时间更少。
总之和画图相比，逻辑占用时间几乎可以忽略。除非游戏画面是静态的……那就当我没说好了=。=

熊的选民

回复 柳柳 的帖子
看是什么类型的游戏了，如果是arpg，而每桢都要计算的话，逻辑占用时间也是很恐怖的。比如我发出一串子弹，每颗子弹每桢都要遍历事件列表检查是否与其他事件相撞。

   

紫苏

底層語句不得力。
禾西 发表于 2010-10-1 10:07

Ruby 1.8 高层也不甚得力，主要还是由于 MRI 直接在语法树上求值，既没有经过优化的中间代码，也没有即时编译的代码 Cache 机制。

之前为了游戏的帧率，用了个微秒测试器仔细测过游戏里所有主要函数在大多数情况下的运行时间。即时以我优化得最差的时候，基本也是逻辑占10%时间左右，渲染占90%
柳柳 发表于 2010-10-1 11:14

不知这个测试器是如何获取渲染时间的？Graphics.update 中进行实际的屏幕渲染也是需要考虑的，但它同时也包括程序空闲时间（不占用 CPU 的时间），直到从调用为止到结束经过了固定的时间（取决于 FPS）才返回。