Project1

标题: 垃圾回收模块GC的问题^^ [打印本页]

作者: 冰水    时间: 2008-1-10 04:17
标题: 垃圾回收模块GC的问题^^
gc清理内存是只局限在对象内部,只对一个对象起作用?
还是用了gc.start后会清理掉所有废弃的.{/pz}

还有gc清理的范围?都会把什么样的目标清除掉.{/hx} [LINE]1,#dddddd[/LINE]版务信息:本贴由楼主自主结贴~
作者: 冰水    时间: 2008-1-10 04:17
标题: 垃圾回收模块GC的问题^^
gc清理内存是只局限在对象内部,只对一个对象起作用?
还是用了gc.start后会清理掉所有废弃的.{/pz}

还有gc清理的范围?都会把什么样的目标清除掉.{/hx} [LINE]1,#dddddd[/LINE]版务信息:本贴由楼主自主结贴~
作者: 美兽    时间: 2008-1-10 05:23
清理掉所有废弃的,

一个对象不再被使用,就会被清除掉。 [LINE]1,#dddddd[/LINE]系统信息:本贴由楼主认可为正确答案,66RPG感谢您的热情解答~
作者: 冰水    时间: 2008-1-11 03:58
{/hx}谢谢美兽殿,
清理所有.看来这个不能经常用了,常用肯定巨卡.^^
作者: 美兽    时间: 2008-1-11 08:31
回收模块默认就是开启的,所以有cache的存在。
作者: 冰水    时间: 2008-1-12 03:46
默认开启{/gg},就是说这个类似个开关喽
    def self.clear
      @cache = {}
      GC.start
    end
默认开启这个方法为什么还要特意加个GC.start
那重复调用RPG::Cache.clear会不会出现什么问题啊?
GC.enable和GC.disable又有什么用。
我先用GC.disable后用GC.start,居然没有跳出任何异常提示{/gg},这是为什么?
作者: 美兽    时间: 2008-1-12 10:22
以下引用冰水于2008-1-11 19:46:15的发言:

默认开启,就是说这个类似个开关喽
   def self.clear
     @cache = {}
     GC.start
   end
默认开启这个方法为什么还要特意加个GC.start
那重复调用RPG::Cache.clear会不会出现什么问题啊?
GC.enable和GC.disable又有什么用。
我先用GC.disable后用GC.start,居然没有跳出任何异常提示,这是为什么?


首先,Cache是个模块,是静态处理,所以@cache会直接占用内存,当bitmap对象装入之后也会保留,RPG::Cache得到的是对象引用,当@cache = {}清空后,虽然@cache没有数据,对象占用的内存空间并没有被释放,此时GC会定时对不被使用的对象进行检查,并自动释放,GC.start是确保垃圾处理的有效,因为GC可以关闭的。

RPG::Cache.clear释放缓存,会影响相同的bitmap的载入速度,毕竟调引用比重新载入要快的多。

至于GC.enable和GC.disable与GC.start的逻辑关系看F1很好理解吧……
作者: 冰水    时间: 2008-1-13 17:51
{/gg}
就是说GC.start只是在确保垃圾处理的有效喽,GC会定时清理内存
GC.disable后可以重新用GC.start清理下内存,

orz,但GC还是默认开启的,谁没事会把GC关掉?RGSS里很多脚本还真是诡异啊。{/fd}
作者: 美兽    时间: 2008-1-13 22:46
以下引用冰水于2008-1-13 9:51:42的发言:


就是说GC.start只是在确保垃圾处理的有效喽,GC会定时清理内存
GC.disable后可以重新用GC.start清理下内存,

orz,但GC还是默认开启的,谁没事会把GC关掉?RGSS里很多脚本还真是诡异啊。


因为垃圾处理消耗资源,如果你能绝对控制对象的内存使用,还是不启用的好。

同时GC存在不确定性,无法确定频率和作用对象,只是以标记形式加入队列等待下次GC才去处理。

只是这些东西对于运算量非常小的RGSS来说没什么大的意义。




欢迎光临 Project1 (https://rpg.blue/) Powered by Discuz! X3.1