Why does saving the game take so long during image saving?

[bx83]

Hi, just wondered something I could know by looking at the code for 4 hours, but this is quicker...

Why does it take so long to save the game when new images are imported? Does it have to: open the compressed image file (long time at 3.5GB); save the new images; index them all again; close the compressed file,
OR
Does it use a custom technique for saving and indexing sprites which is O(n^2) for time, so time increases exponentially with the number of sprites,
OR
Some other reason.

??

[eri0o]

Do you have a SSD?

And if you don't but have enough RAM, you can set a RAM fs on the compiled folder.

[Crimson Wizard]

Does it use a custom technique for saving and indexing sprites which is O(n^2) for time, so time increases exponentially with the number of sprites,

Not exponentially, I think, but linearily, yet it does resave them all again, reading from the previous file, which is very non-optimal indeed, yet no one has worked on improving this, so this is still how it is.

UPD: I guess the main reason is that any of the existing sprites may have changed, so it resaves them all for simplicity. But that is probably still could've been optimized to save only new sprites if nothing else changed.

[bx83]

eri0o: How?

[eri0o]

I don't know how to setup a ramfs on Windows, but I have done in the past on Linux - I think on Linux was just writing the spec on fstab and done. I am sorry, but I use Windows very little. :/

There are some utilities that allows you to map ram on Windows (look for the keyword Ramdisk on Google and find a software from someone you trust) as a drive letter. On latest Windows 10 I know one can setup a seamless link from a folder to a mapped drive. I think on latest Windows may be possible to create a Ramdisk without a third-party software, but I am not sure.

A note that if you have a recent ssd, it's speed will be similar to the Ramdisk - I don't know why, but it is around same speed, it's not insanely fast as one would think.

[bx83]

Not exponentially, I think, but linearily, yet it does resave them all again, reading from the previous file, which is very non-optimal indeed, yet no one has worked on improving this, so this is still how it is.

UPD: I guess the main reason is that any of the existing sprites may have changed, so it resaves them all for simplicity. But that is probably still could've been optimized to save only new sprites if nothing else changed.

So whereabouts is this in the code? I could stare at for 15 hours

[Snarky]

Does it use a custom technique for saving and indexing sprites which is O(n^2) for time, so time increases exponentially with the number of sprites,

Just a small nitpick, but n^2 is not exponential, just polynomial (quadratic, to be precise). For something to be exponential in complexity, it would have to be in the form O(a^n), where a is some constant>1. To call a quadratic progression exponential is a common misnomer.

Edit: Fixed misuse of term.

[bx83]

Whereabouts in the code is it snarky?

[Crimson Wizard]

Here: https://github.com/adventuregamestudio/ags/blob/master/Common/ac/spritecache.cpp#L578