[Suggestion] Speed up the save process

[ApolloLV]

So when saving, the game probably does 'pause game->write game state to disk->resume game'.

So, when we are saving, it just goes through every object currently in the game, and writes its stats to the save file directly.
In this approach, the write speed to the disk is the bottleneck, since computation time is negligible on such operations.
But what if we wrote the game stats to RAM (no, the footprint won't double, its just 15 MB of text).
Now, we resume the game. But we are not stopping saving here, we are starting a new low-priority thread that takes the text from the RAM and saves it to the disk.
(The outcome will be the same, and you will only loose your data if the PC is powered off while saving, which would happen with the direct approach, too)
Yes, we still need to pause the game, but gathering 15 MB of information and writing it to RAM is a matter of milliseconds. You still need to write that to a disk, but that can happen while the game continues.

There are good arguments for 'pausing the game' while writing the save file.
Firstly, it takes time to write all the objects to disk and you don't want objects moving about in the interim. Also it allows more resources to be thrown at the save operation, meaning it is finished sooner.

That is exactly what I wrote about in the original post.

[cfpsmatt]

Has anybody had trouble with the auto-save feature doing something strange if you happen to be placing foundations or an object at the moment the save occurs? I have noticed a couple of times recently that you get odd things happening. You get a shift in position or get a duplication of the item. I was placing a shower head earlier and just as I put it down the auto-save happened, when the game resumed I had placed a duplicate of it about 4 tiles away from where I originally clicked. I haven't seen this in the bug thread, my apologies if it is already there.


cfpsmatt.

[5hifty]

So, when we are saving, it just goes through every object currently in the game, and writes its stats to the save file directly.
In this approach, the write speed to the disk is the bottleneck, since computation time is negligible on such operations.

I'm gunna say its not. I have a highspeed SSD. I still get the freeze when it saves.

[ApolloLV]

So, when we are saving, it just goes through every object currently in the game, and writes its stats to the save file directly.
In this approach, the write speed to the disk is the bottleneck, since computation time is negligible on such operations.

I'm gunna say its not. I have a highspeed SSD. I still get the freeze when it saves.

Yes, the freeze is inevitable, but the question is: how long does it freeze. Do you have a HDD, too?

[xander]

...we are starting a new low-priority thread that takes the text from the RAM and saves it to the disk.

Which is what I have been saying from the start is the right solution, and which is different from what you have posted until now (or, at least, you have failed to communicate this). "Saving" the game to RAM before writing to disk is not the thing that keeps the game from freezing. Creating a new thread that can write to disk in the background is what does that.

xander

[ApolloLV]

I would suggest the method collecting the savegame information writing the info to a String, and after being done, invoking a method that writes the string to the disk while also releasing the game action

[5hifty]

So, when we are saving, it just goes through every object currently in the game, and writes its stats to the save file directly.
In this approach, the write speed to the disk is the bottleneck, since computation time is negligible on such operations.

I'm gunna say its not. I have a highspeed SSD. I still get the freeze when it saves.

Yes, the freeze is inevitable, but the question is: how long does it freeze. Do you have a HDD, too?

Never timed it, but it's a good couple of seconds at least. And yeah I have about 4 other HDD, none of which are relevant. They aren't even spun up when I'm gaming.

[ApolloLV]

Never timed it, but it's a good couple of seconds at least. And yeah I have about 4 other HDD, none of which are relevant. They aren't even spun up when I'm gaming.

Could you time the difference between SSD and HDD? At least on Linux, you can Symlink the Save Folder location to another Drive, so you can compare them.

[xander]

I would suggest the method collecting the savegame information writing the info to a String, and after being done, invoking a method that writes the string to the disk while also releasing the game action

...which is different from what you have posted until now (or, at least, you have failed to communicate this).

Your have consistently emphasized the fact that you are writing the save file to RAM before writing it to disk. Since this has nothing to do with parallelizing the save process and doesn't actually make the process of saving a file happen any faster, perhaps you can understand my confusion and the emphasized portion of text above.

xander

[ApolloLV]

Sorry I wasted some of your time, Xander, but English is just not my native language. I am happy I finally was able to make my point clear (I hope). All I care about is whether or not we can make PA a better game (from the technical point of view). I just hope some Dev finds this sometime...

I filed a bug report, you can find it here: http://bugs.introversion.co.uk/view.php?id=4113
@Xander, @Paktsardines If my explanation on the report is not easily understandable, feel free to add your own.

So long, and thanks for all the fish,
ApolloLV

[prg]

You claim saving takes 20 seconds to produce a 15MB file and that the long time is somehow because of slow HDD speeds. But even a slow HDD already writes 50MB/s so this quite obviously can't be the problem.

So, when we are saving, it just goes through every object currently in the game, and writes its stats to the save file directly.
In this approach, the write speed to the disk is the bottleneck, since computation time is negligible on such operations.

Let's take a look at the output the game produces when saving.

Code: Select all

Saving map to '$file'...Save completed in 1982ms (1858ms to serialise world, 124ms to write file)

So you have it exactly backwards, turning the game state into text takes about 15 times as long as actually writing the result to a file.

As for the idea of first writing to RAM, that's pretty much what's getting done by the OS anyway. Writes are heavily cached, there are no guarantees that the data actually made it to the drive when a write call returns. If you care about that you have to call something like fsync after the write to wait for completion.

[b0rk]

The issue appears to be more serialisation (in memory) then write to disk... The game has to take whatever lovely memory efficient structures that have been developed and convert them into plain text as per below:

BEGIN "[i 38]"
id 38
TopLeft.x 163
TopLeft.y 80
BottomRight.x 165
BottomRight.y 89
Centre.x 164.500
Centre.y 85.5000
Indoor true
NumSquares 30
NumFloorSquares 13
Zone StaffOnly
BEGIN Stations Size 0 END
BEGIN Jobs Size 0 END
END

It would IHMO to be more sensible to argue for a more efficient save format rather than plain text or for the game to create a in memory copy of the efficient internal structures then serialise the copy in a worker thread. A simple test is to save to conventional disk then try again this time saving to RAM disk, you'll notice no noticeable difference in overall save time.

[xander]

It would IHMO to be more sensible to argue for a more efficient save format...

I disagree. One of the really nice features of Introversion's games is that the save files can easily be edited by hand without requiring that much technical knowledge (yes, Darwinia and Uplink both use a simple encryption algorithm, but the files are easily deciphered using command line utilities or particular websites that have been set up for the tast, and unencrypted files can be read by the games). An open, easily edited, plain text save file format is a feature, not a bug.

xander

[nzjoe87]

[edit: Didn't see page 2 while posting this, seems by page 2 we made it to the real problem!] While you all have some interesting theories have we considered the fact the the collections used to for data storage in game are simply not optimized? It takes time to iterate over large collections of objects and as every tile in the game is an object you can understand why the save takes so long. Try tiling out a whole map of rooms and then deleting them, the method for deletion is O(n) and so I can only presume the the that copying every object is also going to get iterated over in O(n). you have large maps, lots of tiles, lots of variables, lots of characters. You don't optimize heavily when you are still deep in development because you may entirely remove a system or rework it at a later date.

I sincerely doubt given HDD/SDD/RAM speeds in this day and age that the writing of the save data is the issue, it is far more likely to be a combination of a lack of parallelisation and the storage/sorting methods used.

This is an Alpha, Chris was adding features, now Chris is fixing bugs. At no point have I seen Chris offer to optimize and I think it would be silly for him to invest time in it at this point. Saves will take time, they most likely won't take any where near as long when the game hits a Beta state.

aaand because the post annoyed me: Computation time is never negligible when dealing with data structures.

[b0rk]

I disagree. One of the really nice features of Introversion's games is that the save files can easily be edited by hand without requiring that much technical knowledge <snip> An open, easily edited, plain text save file format is a feature, not a bug.

I actually agree that the text save files are a feature and I would like them to remain personally. However if the time penalty is in serialisation I don't really see what could be done to reduce this without making to format more efficient, I assume IV have semi optimised serialisation routines taken from previous games so the quick wins optimisation wise may well have been taken. Loads for example appear to be remarkably rapid.