Faster savegame

[radcapricorn]

Actually they may not be saved

Indeed, that's a much better wording

[harokyang]

I don't care if game has to be paused during save
But please use all the core while saving

[Slashman]

I don't care if game has to be paused during save
But please use all the core while saving

How would using all the cores while saving help with the task of saving?

[bobucles2]

Because those "objects" don't exist in a vacuum, so to speak (pun not intended). A save need to represent a singular moment in time, otherwise it will contain inconsistent data. You cannot be saving a live running state in the background, simulation has to be paused.

So fork the game state? The vast majority of video game assets are 3d, textures or sounds, and those are hardly important to the saving process. Only the core sim needs to be copied. If the entirety of the core save data can be written out as 500MB of raw bloated xml, then a spare GB of memory space (which high end systems have) can hold a snapshot of the game state.

It does make sense that there should be a 100% reliable save option, especially since X4 doesn't run backups of save files. However, I'll take a 90% reliable quicksave if it only costs a few seconds for a deep copy and runs the rest in the background. A fast save encourages more saving, which ultimately means less lost progress overall.

[CBJ]

You don't appear to have read the rest of the thread, bobucles2. As has already been explained, you can't "fork" the game state because it's not an amorphous mass of data that can just be copied from one place to another. Replicating each and every element, one by one, which is what would have to happen, would make the process take even longer!

[bobucles2]

Oh yes, the total process would be overall larger, by quite a bit. However, the game sim only needs to be frozen during the copy process. After the data is copied, a side process can do whatever it wants. So instead of a 30 second pause/serialize/write there's a 5 second pause, with a 30 second spinning disk in the corner. Then Betty eventually says if the save was successful or not. That's perfectly doable for a rotating quicksave or autosave. If the copy is quick enough it could even work every few minutes instead of every hour. The regular save is reliable and works fine as is.

The big issue is the sheer bulk of RAM required to perform such a massive copy. There are many things that don't need to be copied, but the entire snapshot (sans assets) would still be pretty big, big enough to crash some systems. That leaves it only as an option for high end systems.

[CBJ]

There are plenty of things that don't need to be copied, but you drastically underestimate the number that would and the time it would take to do so. Bear in mind that it would require the exact same traversal that is currently undertaken to generate the serialised output, but instead of a simple text output, it would need to recreate complex object structures.

[Shorinji]

Hi CBJ,

First, thank you for taking the time to answer to us about this issue.

Is it possible for you to explain why saving does not use the maximum processing power of my processor?

On my system:
-running the game uses between 10% and 50% of the processor cores (it varies with time).
-saving with compression takes 31 seconds, there is a usage spike up to 85% for the last 10 seconds, on only one core.
-saving without compression takes 25 seconds, and there is no spike.

There is no usage spike on my harddrive.

What is the bottleneck exactly? Is it RAM access speed?

[CBJ]

As previously explained, serialisation is an essentially linear process and a large proportion of it can only really be done using one core. I'm afraid I can't say why the process wouldn't use the whole of that core's availability (if indeed that is the case - quite often tools that report CPU usage are not entirely accurate anyway) but memory access (not just latency, but various issues associated with memory allocation and re-allocation too) would be a decent guess.

[harokyang]

Have you benchmark the cost of your XML parser?
IO of huge XML file is also time consuming

[Rei Ayanami]

I don't care if game has to be paused during save
But please use all the core while saving

How would using all the cores while saving help with the task of saving?

This is just a wild "how would i do it"-guesswork, but perhaps, if a dev at Egosoft is bored and wants to rewrite the saving process and needs inspiration/input for ideas :
And please, by no means take this as "i know better than the devs", the devs know X4s inner workings far better and have spent far more time on it than me, this post is just for fun as a thought-experiment .

There is a lot of work that theoretically COULD be split up unto multiple threads/core jobs, depending on how X4 internally stores it's data (how the object reference graph is connected). Instead of traversing the object reference graph of the entire universe as one giant process, the problem could be split up into each core traversing only the object relation graph in each sector and then, one core after another, writing their processed sector data into the savegame.

Wall of text with details, only for those who are interested

Spoiler

Show

First, single-core serialize all "unique" data that only occurs once (faction relations, player state, known encyclopedia entries, quest status, etc), just like it happens now. Write that into the savegame.
Now the savegame content so far would look like (very much abstracted):
[unique data]

Then use multithreading to process the "repeating" data, aka ships, stations, ai orders, etc that theoretically could be written in any order (whether i write ship/station data for sector A or sector B first into the savegame shouldn't matter, its the savegame loader that'll have to stitch together the cross references between objects) :
First, make a list of references to all sectors in the universe.
Then, have each core take one sector reference each out of that list and serialize their sectors content (owner/ships/stations/projectiles/boxes/etc) to a temporary buffer in RAM. While traversing the object hierarchy of this sectors objects, if an object in this sector references a ship/station/etc outside the currently examined sector, stop traversing this graph path (each sector-serialization job only cares about its own sector), just save the reference of the not-in-this-sector-object (another core will take care of the object in the other sector) and continue traversing the graph in the current sector.

If the entire sector graph has been traversed and no other core is currently writing its buffer to the savegame, append current sectors byte buffer to the savegame. If another core is currently writing to the save file, this core has to wait until the other core is done. After the first sector write, the savegame content would look like (again, very simplified, the 0x... is simply the reference ID for that object)
[unique data]
[sectorA][sector data][ship in that sector:0x123456][ship data][ship in that sector:0x257941][ship data][station in that sector:0x321124][station data][etc data in that sector] (loot, wrecks, etc and so on)

After the second sector and its content is written, the savegame would look like this :
[unique data]
[sectorA][sector data][ship:0x123456][ship data][ship:0x257941][ship data][station:0x321124][station data][etc data in that sector] (loot, wrecks, projectiles, etc and so on)
[sectorB][sector data][ship:0x364792][ship data][ship:0x335412][ship data][station:0x145030][station data][etc data in that sector] (loot, wrecks, projectiles, etc and so on)

After a core appended the buffer into the savegame, clear the buffer and pick the next unprocessed sector in the list.
Repeat until no more sectors are in the list.

You'd end up with a list of all sectors, and after each sector entry there'd be a list of data about all objects in that sector. Theoretically the object graph traversal speed for examining and serializing the universe could go up with each additonal core available. Depending on how X4 loads a savegame/game object, loading a game could perhaps also be partially multithreaded, again with each thread loading one sector at a time, and after all sectors/objects are loaded, another pass over everything would fix up the references.

The main issue i'd guess is that X4, if i remember the savegame format correctly, currently uses a totally different format/object order/XML schema for storing game data than what my multitreaded idea would produce. Ohwell...