config.image_cache_size: determining an optimal low‑memory limit for low‑traffic deployments

Goal: Reduce RAM usage in a low‑traffic visual novel by capping the image cache size

Ren'Py keeps decoded images in an in‑memory LRU cache whose size is governed by config.image_cache_size. When the limit is zero (the default), the cache can grow without bound, which is wasteful for projects that rarely load many distinct assets. Setting a positive limit caps the number of distinct images retained, but can trigger reloads when the limit is exceeded, potentially causing frame stalls on devices where decompression is costly.

The key uncertainty is what value balances memory savings against performance degradation for a given asset set. Large texture atlases count as a single cache entry, so the effective working set can be smaller than the raw number of images. Additionally, driver‑level texture caches may mask the impact of the Ren'Py limit.

To make an informed decision, we need to understand:

• What is a safe config.image_cache_size value for a game with ~200 unique sprites that rarely change?
• How does the cache limit interact with texture atlases and the underlying graphics driver’s cache?
• Is there a runtime API to adjust the limit without restarting the game?