【不是创意的创意】RM内存自动清理脚本（XP&VX） v 1.00

第七水螰

這個或許解決了 Ruby 1.8 的 mark-and-sweep GC 算法太過保守的問題，因為默認情況下只有在 Ruby 堆負載過高時 GC 才開始回收。Cache 和 GC 是兩碼事，Cache 是一種緩存優化，GC.start 是開始進行回收失去引用以及只有弱引用內存的過程，當 cache 中的內容沒有被清除時，GC.start 並不能回收 cache 中的內存。上面 @Shy07 說「Cache貌似可以直接扔掉了」不知是出於什麼邏輯？如果沒了 cache，就失去了緩存的優勢。Cache 本身應該有一個良好的 cache 算法，將 cache 塊固定在一個大小，而不是像 RM 這樣無限生長，這是 RM 的缺點。很多程序運行時間越久就越慢就是因為 cache 越來越大，從未被清理。

第七水螰

Shy07 发表于 2011-11-22 09:27
Cahce.clear是整个RGSS2可见部分唯一调用到GC.start的地方，我觉得eb的本意是让用户自己在事件或脚本中手 ...

原來是這個意思，看四樓說「Cache貌似可以直接扔掉了」，我完全理解為「cache 沒有用」了。

我觉得eb的本意是让用户自己在事件或脚本中手动调用Cache.clear [...] 如果要严格控制内存的话，其实可以在Scene.start里用Cache.load_bitmap加载该场景需要的所有位图，Scene.terminate里调用Cache.clear，清空内存并进入下一个场景

你說的很貼近於一種叫 Belady's Algorithm 的 cache 算法，即 cache miss 時總是拋棄未來不會使用的時間最長的內容。然而，這種思路在實踐時幾乎沒有可行性，因為在足夠動態的環境下根本無法確定某個信息是否還會被引用或是會被引用多長時間。手動清空 cache 時，如何能確定清空的位圖在下一個場景中不會被使用？如果這些位圖僅存在於一個場景中，那「在該場景中重複加載這些位圖」的概率能有多高？相比於「在所有場景中反復加載這些位圖」的概率來說自是不算高。按照十一樓提出的方法，「在一個場景中重複加載位圖」的概率越高，cache 的價值才越高，而「別的場景也加載相同位圖」的概率越高，cache 的價值就越低。在編程時或許能確定場景 A 和 場景 B 都用到了位圖 P 而場景 C 沒有用到，但在運行時卻無法預料遊戲到底會過渡到場景 C 還是場景 A、B。 目前 RGSS 的 cache 就像一個巨大的位圖池，無論是在什麼場景使用某個以文件路徑標識的位圖，只要經過了 cache 這層，就永遠只需要加載一次，所以它壓根沒有考慮訪問局部性之類的 cache 問題，它只是默認已經擁有可以快速查閱的表。在一個理想的（無限內存） RAM 計算模型下這是時間上最優的一種設計，但在實踐時卻需要考慮計算機內存的有窮性。

CPU cache 可以看作是 cache 算法的最基本也是最重要的一個應用，不同的硬件採用的 cache miss 處理算法也不同，像拋棄最不常用數據的 LRU，拋棄最常用數據的 MRU，隨機化的 RR 等。RM 理論上完全可以實現這樣的一個 cache。

第七水螰

禾西 发表于 2011-11-23 14:22
在不確定要使用多少內存的情況下討論緩存管理，有意義嗎（挖鼻孔）Ruby的GC和RM的Cache完全是彼此對立的兩 ...

RGSS 默認的 cache 是用了多少內存就有多少緩存，這會導致資枯竭問題。我們討論的是給 cache 塊的大小加一個上限，無論內存的使用量如何，緩存都只能這麼大。