Fresh currently keeps every loss entry until the history is cleared manually. The full history is loaded into memory, rewritten to rm_FreshLog.xml when the game is saved, and sent to clients when they join a multiplayer game. Several statistics and daily notification calculations also scan the history.
This is probably negligible for most saves, but there is no upper limit. On a long-running save—particularly a busy dedicated server—the history, save file, and join-sync payload can only grow. The existing clear action removes everything, so there is no middle ground between retaining the complete history and losing it altogether.
Would you consider adding some form of retention policy?
One option would be to keep detailed entries for a recent rolling window, then summarize older entries by farm, fill type, and period. That could preserve useful totals while preventing the detailed history from growing indefinitely. A simpler configurable age or entry limit would also address the growth.
I have not measured a noticeable slowdown during normal play, so I see this as preventive maintenance rather than a confirmed performance problem. Before choosing a limit, it may be useful to generate histories of increasing size and compare:
rm_FreshLog.xml size- save and load time
- statistics screen response time
- multiplayer join time and synchronization size
Fresh currently keeps every loss entry until the history is cleared manually. The full history is loaded into memory, rewritten to
rm_FreshLog.xmlwhen the game is saved, and sent to clients when they join a multiplayer game. Several statistics and daily notification calculations also scan the history.This is probably negligible for most saves, but there is no upper limit. On a long-running save—particularly a busy dedicated server—the history, save file, and join-sync payload can only grow. The existing clear action removes everything, so there is no middle ground between retaining the complete history and losing it altogether.
Would you consider adding some form of retention policy?
One option would be to keep detailed entries for a recent rolling window, then summarize older entries by farm, fill type, and period. That could preserve useful totals while preventing the detailed history from growing indefinitely. A simpler configurable age or entry limit would also address the growth.
I have not measured a noticeable slowdown during normal play, so I see this as preventive maintenance rather than a confirmed performance problem. Before choosing a limit, it may be useful to generate histories of increasing size and compare:
rm_FreshLog.xmlsize