Friday Facts #201 - 0.15 Stable, but not really

Regular reports on Factorio development.
ratchetfreak
Filter Inserter
Filter Inserter
Posts: 950
Joined: Sat May 23, 2015 12:10 pm
Contact:

Re: Friday Facts #201 - 0.15 Stable, but not really

Post by ratchetfreak »

abordoli wrote:I'm auto-saving every 30 minutes and, tbh, I don't even know why I'd save that frequently. I DO gather that the longer "in between" saves, the longer the save operation will be. I'm quite betwixt as I'd rather saves not bother me at all, but then again..."a stich in time...saves nine" keeps nagging at me.
~B
Each auto save is independent from the previous save. It's a full save every time without any optimizations based on the previous save

bobucles
Smart Inserter
Smart Inserter
Posts: 1669
Joined: Wed Jun 10, 2015 10:37 pm
Contact:

Re: Friday Facts #201 - 0.15 Stable, but not really

Post by bobucles »

But saving taking 20-60 seconds is not uncommon.
No, that is exactly what uncommon means. I've seen plenty of beefy UPS killing bases in the middle of nowhere and they take no more than 10 seconds to save. Reaching a full second of save time is an accomplishment in of itself. If saving the map is approaching up to a minute that means:

- You have a literal potato toaster or
- A mod is grossly misbehaving

Neither of those problems are the dev's fault. In fact the first problem can't be solved with live action saving because, as you might expect, a toaster can barely run the game without distractions as is. Doubling the system requirements won't make a potato faster. It'll make the potato crash and burn. The second problem can't be solved by devs because they didn't make it. You'll have to work with the mod author to figure out just exactly what they're goofing up that causes save times to skyrocket.
I think I mentioned I had saves take 10+ minutes.
Congratulations on reaching levels of slow no one ever thought possible. Tell us your secrets.

posila
Factorio Staff
Factorio Staff
Posts: 5201
Joined: Thu Jun 11, 2015 1:35 pm
Contact:

Re: Friday Facts #201 - 0.15 Stable, but not really

Post by posila »

NotABiter wrote:Oh, and fork() isn't available on Windows. My scheme works under all OSes. Why is anyone still talking about fork?

(The devs aren't going to do any of this so the discussion is not useful for that. But I was once again "triggered" by people posting *false* information.)
I like your proposal, I think we should definitely do it if Factorio 2 ever happens, but I don't see it happening in the current one.

mrvn
Smart Inserter
Smart Inserter
Posts: 5682
Joined: Mon Sep 05, 2016 9:10 am
Contact:

Re: Friday Facts #201 - 0.15 Stable, but not really

Post by mrvn »

bobucles wrote:
But saving taking 20-60 seconds is not uncommon.
No, that is exactly what uncommon means. I've seen plenty of beefy UPS killing bases in the middle of nowhere and they take no more than 10 seconds to save. Reaching a full second of save time is an accomplishment in of itself. If saving the map is approaching up to a minute that means:

- You have a literal potato toaster or
- A mod is grossly misbehaving

Neither of those problems are the dev's fault. In fact the first problem can't be solved with live action saving because, as you might expect, a toaster can barely run the game without distractions as is. Doubling the system requirements won't make a potato faster. It'll make the potato crash and burn. The second problem can't be solved by devs because they didn't make it. You'll have to work with the mod author to figure out just exactly what they're goofing up that causes save times to skyrocket.
I think I mentioned I had saves take 10+ minutes.
Congratulations on reaching levels of slow no one ever thought possible. Tell us your secrets.
Install AAI mods, mark a zone with 800k tiles. Enjoy.

I'm assuming the mod isn't misbehaving but serialization has to call some lua code for every one of those 800k marked tiles. That's bound to be slow no mastter what.

Dave64738
Inserter
Inserter
Posts: 29
Joined: Wed Apr 13, 2016 10:37 pm
Contact:

Re: Friday Facts #201 - 0.15 Stable, but not really

Post by Dave64738 »

Regarding optimisations, have you considered using database techniques to optimise out that huge annoyance that is Autosave? A large production database cannot afford to lock up for several minutes every few minutes to write everything to disk; if you use an approach like the redo log stuff in Oracle you might be able to remove autosave alrogether.

Of course, there would be stuff that would need working out; there is no point restoring a game after being killed to the point immediately before you die, but you could perhaps restore to a player-specified time before that (maybe even visually rewind the gameplay so that the player can determine where to restart).

A redo log equivalent might also make some hard-to-find bugs easier to reproduce, if you are able to recover the last save plus the redo, you would get much closer to the bug before having to guess what happened next. Currently the only checkpoint is the last auto or manual save.

pleegwat
Filter Inserter
Filter Inserter
Posts: 255
Joined: Fri May 19, 2017 7:31 pm
Contact:

Re: Friday Facts #201 - 0.15 Stable, but not really

Post by pleegwat »

Dave64738 wrote:Regarding optimisations, have you considered using database techniques to optimise out that huge annoyance that is Autosave? A large production database cannot afford to lock up for several minutes every few minutes to write everything to disk; if you use an approach like the redo log stuff in Oracle you might be able to remove autosave alrogether.

Of course, there would be stuff that would need working out; there is no point restoring a game after being killed to the point immediately before you die, but you could perhaps restore to a player-specified time before that (maybe even visually rewind the gameplay so that the player can determine where to restart).

A redo log equivalent might also make some hard-to-find bugs easier to reproduce, if you are able to recover the last save plus the redo, you would get much closer to the bug before having to guess what happened next. Currently the only checkpoint is the last auto or manual save.
While it's a nice idea, I fear that occasional full snapshots are still required, as replaying the redo log is likely to take just as much CPU as playing the game initially did. So if your megabase needs to load a point half an hour after the last snapshot, it will likely take half an hour to load the save.

mrvn
Smart Inserter
Smart Inserter
Posts: 5682
Joined: Mon Sep 05, 2016 9:10 am
Contact:

Re: Friday Facts #201 - 0.15 Stable, but not really

Post by mrvn »

pleegwat wrote:
Dave64738 wrote:Regarding optimisations, have you considered using database techniques to optimise out that huge annoyance that is Autosave? A large production database cannot afford to lock up for several minutes every few minutes to write everything to disk; if you use an approach like the redo log stuff in Oracle you might be able to remove autosave alrogether.

Of course, there would be stuff that would need working out; there is no point restoring a game after being killed to the point immediately before you die, but you could perhaps restore to a player-specified time before that (maybe even visually rewind the gameplay so that the player can determine where to restart).

A redo log equivalent might also make some hard-to-find bugs easier to reproduce, if you are able to recover the last save plus the redo, you would get much closer to the bug before having to guess what happened next. Currently the only checkpoint is the last auto or manual save.
While it's a nice idea, I fear that occasional full snapshots are still required, as replaying the redo log is likely to take just as much CPU as playing the game initially did. So if your megabase needs to load a point half an hour after the last snapshot, it will likely take half an hour to load the save.
But at least you don't have to do all the clicks again. And he did say "last save plus the redo".

I would really like it if one could load a save from say 10 minutes ago plus the redo and let it run. An then at some point, say 5 minutes in you hit stop and do something different and play again.

jerocom
Burner Inserter
Burner Inserter
Posts: 12
Joined: Sun Jun 11, 2017 7:24 pm
Contact:

Re: Friday Facts #201 - 0.15 Stable, but not really

Post by jerocom »

1.83 seconds to generate new map... and here am I, with my perfect PC, generating new map 3 minutes :D

User avatar
Durabys
Fast Inserter
Fast Inserter
Posts: 233
Joined: Mon Apr 18, 2016 3:30 pm
Contact:

Re: Friday Facts #201 - 0.15 Stable, but not really

Post by Durabys »

jerocom wrote:1.83 seconds to generate new map... and here am I, with my perfect PC, generating new map 3 minutes :D
Hmmm. What CPU do you have? Maybe it is the problem that the Devs are optimizing the game on one set of CPU's and Software Drivers and once the update comes there will be many people complaining: "BUT IT DOESN'T LIKE WITH THE DEVS!"

Post Reply

Return to “News”