ZDoom

Interestingly Cities: Skylines autosaves w/o any major stutter that I can easily observe on pretty big cities, like more than 150000 citizens in play. I even completely forgot about autosaving being a thing so when I went to purge old saves my jaw dropped as the game turned out to keep making them on the regular w/o me noticing.

EDIT/ After thinking about this some more I think I finally absorbed all your points, thank you for your patience.

Still curious as to how other games manage it. To be fair whatever the solution is is definitely the road less taken and most games do stutter while saving. Maybe it requires structuring things with this goal in mind from the outset... It's not really something I've seen all that often, it's just something I really notice when it's happening because I'm so used to games stuttering on save.

EDIT/ I probably shouldn't keep thinking about this since I don't know enough, but it's really got its hooks in me so here's my final crack at it: You have duplicate sets like I was saying, freeze the second set to serialize and everything else you have to do, and while this is happening for every tick that goes by somewhere else you keep track of the addresses that changed in the first set, and then when the save process is complete you freeze the first set (halt the game) only long enough to write the newest info into the second set. Given the time of the overall save process, and the amount of data that can change per tick, could the amount of data that would need to be updated in the second set represent a significant enough copy time to delay a frame, given the frame times needed to satisfy the typical display rate? Is it wishful thinking on my part to imagine this would be significantly faster than the actual save routine itself?

You still need to copy all the data and keep it in sync with the actual play version, so no, it's not as trivial as you may think.

OK I accept it's likely a bad idea (forgive my ignorance), but if you don't mind can you please explain a little further? When I say the overall memory footprint wouldn't increase that much, I don't mean in terms of percentages, but in terms relative to the amount of RAM that modern systems have. So let's say while the game was running every memory address that has anything to do with game state (as distinct from things like textures and sounds and other assets) had a mirror in another address, and when a save is initiated these mirrored addresses are frozen while a separate thread does all this intensive stuff with it, how would this impact the game thread? Would this represent a significant constant performance impact, in addition to the increased memory footprint?

I have seen games that can save without introducing any stutter (you often see a little progress wheel icon until the process is complete or something), so I'm curious as to how this is usually accomplished.

You have no idea...
The savegames are this small because a) they are compressed and b) are differential saves against initial values. Furthermore, all actors are separately allocated objects that need their class structure intact for the savegame code - so you can't just copy the data around and hope it still works - you have to initiate a copy constructor for each single actor and thinker on the map to make a copy.

The entire game needs to effectively pause while data is being serialized, so I can't see this happening.

So anyone who has seen some of my other posts on these forums know how much I hate any kind of in-game stutter, and to that end I always play with autosaves disabled because a lot of mods have a habit of autosaving mid level, and I can't stand the unexpected microfreezes this causes. Quicksaves don't typically bother me because it's something I'm initiating, so the freeze doesn't catch me by surprise.

As I imagine it the freezes are a result of the game stopping so the memory locations being written out don't change before the save process is finished. If so, it seems the solution would be to just have redundant memory locations for all the savegame relevant data, where the game thread only needs to be able to interact with one to continue, and only freeze the non-critical set while saving. When I look at savegame file sizes they don't seem that big so I cant imagine the overall memory footprint would increase all that much.