Tom Leys

New PR https://github.com/space-wizards/RobustToolbox/pull/5152 helps mitigate effects of less checkpoints by spreading the processing of later ticks over many frames.

Seems the issue is similar to what moonheart08 says. The entire replay is loaded into ram from zlib compressed files, then processed into checkpoints. We might need to move to...

> That's all well and good but the checkpoints are the real killer. Even if you stream the actual regular playback data, the checkpoints will continue to take almost all...

So I went and bought new ram today because I only had 16GB up to now. So I can run a development environment while working on this problem :D I...

These CVARs controlling checkpoint creation look promising. I might spend some time tuning these to reduce the number of checkpoints to less than loaded data as a starting point. ```...

Okay, so it turns out that what I just posted above was wrong. It seems that creating checkpoints is churning through a ton of short-lived allocations and this creates deceiving...

So it seems that checkpoints have been decreased from 1/3 of persistent memory on this snapshot to 1/6. The natural next step is smarter streaming of the replay data from...

I have removed the short-lived allocations during checkpoint creation (so 8GB less memory thrashing). Streaming replays from disc is a much larger change so I probably shouldn't take that on...

I think the PRs that I have provided are good enough to resolve this issue. I expect that loading times will have improved dramatically for affected users and wouldn't be...

> Seems like this may have been fixed? Recently, I was able to load a replay almost as fast as the regular client, and I only have 6GB of memory....