Saving game slows my game down...?

[hasen6]

I managed to solve my save game problem thanks to those on the forum but one problem is that since I’m saving the game on every move, the game seems to get slower and slower as the game goes along? Not sure why this is since I’m not saving anything huge.

The save game function is like this:

 saveGame = function() local gameSettings = { moves = moves, savedeal = savedeal, saveHistory = saveHistory, shuffle = shuffle, } loadsave.saveTable( gameSettings, "settings.json" ) end,

Moves is just an integer, savedeal and shuffle are arrays of simple one or two digit integers. _saveHistory _contains a little more since it contains move information but still is just numbers and the odd string here and there. Not sure why these would take up more and more memory or whatever is making the game slower and slower? _saveHistory _starts empty and builds with each move, but by only about 20 or perhaps less moves the game has slowed considerably.

EDIT: It’s just the saveHistory that is doing it but I’m not sure why saving it would cause the game to slow down. Since it’s being stored in an array where I save the game or not.

[nick_sherman]

First step is to to time how long saveGame takes to execute. Store system.getTimer() before and then compare it after.

If it increases to beyond a few ms, then you are possibly saving too much data (or in an inefficient way) for the game to be responsive. I see that you re-save all the data each time, rather than the changes.

I take it once the shuffle is done this doesn’t change, so could be just saved once at the start?

Better yet, store the random seed used to perform the shuffle and then you just need to store one number.

[nick_sherman]

I see you edited, guess we’d need to see how saveHistory is constructed to work out the bottlenecks.

[anon63346430]

First, comment out the save and confirm that you get no slow down - just incase.

[remiduchalard]

Do you need to save all at each move? Can you save only at game quit or finish or when the app is suspend ?

[hasen6]

@nick\_sherman

First step is to to time how long saveGame takes to execute. Store system.getTimer() before and then compare it after.

If it increases to beyond a few ms, then you are possibly saving too much data (or in an inefficient way) for the game to be responsive. I see that you re-save all the data each time, rather than the changes.

I take it once the shuffle is done this doesn’t change, so could be just saved once at the start?

Well the savehistory changes on every move so it is only saving on changes. The savehistory is what records each move made after the deal.

@nick\_sherman

I see you edited, guess we’d need to see how saveHistory is constructed to work out the bottlenecks.

So basically it’s taking too long to save? But it’s not slowing down WHEN it saves, it’s slowing down progressively. By the time I have made like 30 moves it’s very slow, if I go on to 40 or 50 moves then it’s too slow to play.

[hasen6]

@anon63346430

First, comment out the save and confirm that you get no slow down - just incase.

Yes it’s fine all the way without the saving. And I confirmed with the edit above that’s in only the savehistory that is slowing the game down. Saving the other stuff causes no problem.

@remiduchalard

Do you need to save all at each move? Can you save only at game quit or finish or when the app is suspend ?

I could save on game quit but I’m not sure how to do that. It would have to save if the user was on the game screen (ie he did not return to the menu) double clicked the home button on iPhone and swiped to remove the game. That would be fine if that were possible but still it wouldn’t save if his phone ran out of power mid game.

[nick_sherman]

What’s the structure of saveHistory? How is it built?

The bigger and more complex the table, the longer json.encode will take to work. But it sounds like you’re experiencing low fps even after the save has happened? If you just drag objects around without actually making a successful move, is there lag?

[hasen6]

@nick\_sherman

What’s the structure of saveHistory? How is it built?

The bigger and more complex the table, the longer json.encode will take to work. But it sounds like you’re experiencing low fps even after the save has happened? If you just drag objects around without actually making a successful move, is there lag?

The first 10 moves the game is still responsive but it has already saved 10 times. The game just gets progressively slower so I don’t think it’s anything to do with encoding. The saves happen instantly with no wait at all.

But later on everything is slow. Which could be the encoding time taking longer and longer due to the data getting bigger and bigger.

The structure is like this:

 table.insert(saveHistory, { moveType = moveType, -- string ie "draw" etc data = data,-- contains various tables...could be the problem order = data.card.order, -- a number between 1 and 52 target = data.target.order, -- a number between 1 and 52 top = data.target.top, -- a number between 1 and 4 table = data.target.table -- a number between 1 and 7 })

EDIT: I can confirm it’s the data field that is slowing the game down. Commenting just that field out when saving the game eliminates the slow down completely. I guess I can have a look if perhaps some of what is in there doesn’t need to be saved.

[anon63346430]

@hasen6

The first 10 moves the game is still responsive but it has already saved 10 times. The game just gets progressively slower so I don’t think it’s anything to do with encoding. The saves happen instantly with no wait at all.

But later on everything is slow. Which could be the encoding time taking longer and longer due to the data getting bigger and bigger.

I am confused… if it was the encode>save that was slowing your game would just drop some frames and then carry on as normal.

Check your memory allocation and display object count in an enterframe and see if that yields any surprises.

Regarding saving, you can save on app suspend (this will get called in all but battery-died state changes).

[hasen6]

@anon63346430

I am confused… if it was the encode>save that was slowing your game would just drop some frames and then carry on as normal.

Check your memory allocation and display object count in an enterframe and see if that yields any surprises.

Regarding saving, you can save on app suspend (this will get called in all but battery-died state changes).

No it wouldn’t because the save is getting bigger and bigger since the move history (savehistory) is getting bigger as its recording every and _all _moves. So each time it comes to save it’s a bigger save than the last. It also couldn’t ‘carry on as normal’ since in a solitaire game, if you’re not making a move the game may as well be paused. So every move is a save as it has to save every move, therefore every move is slow since it saves when a move is made.

Anyway that was it so thanks to everyone’s help. I trimmed the data field down to save only what I needed and now the problem is solved.

[nick_sherman]

First step is to to time how long saveGame takes to execute. Store system.getTimer() before and then compare it after.

If it increases to beyond a few ms, then you are possibly saving too much data (or in an inefficient way) for the game to be responsive. I see that you re-save all the data each time, rather than the changes.

I take it once the shuffle is done this doesn’t change, so could be just saved once at the start?

Better yet, store the random seed used to perform the shuffle and then you just need to store one number.

[nick_sherman]

I see you edited, guess we’d need to see how saveHistory is constructed to work out the bottlenecks.

[anon63346430]

First, comment out the save and confirm that you get no slow down - just incase.

[remiduchalard]

Do you need to save all at each move? Can you save only at game quit or finish or when the app is suspend ?

[hasen6]

@nick\_sherman

First step is to to time how long saveGame takes to execute. Store system.getTimer() before and then compare it after.

If it increases to beyond a few ms, then you are possibly saving too much data (or in an inefficient way) for the game to be responsive. I see that you re-save all the data each time, rather than the changes.

I take it once the shuffle is done this doesn’t change, so could be just saved once at the start?

Well the savehistory changes on every move so it is only saving on changes. The savehistory is what records each move made after the deal.

@nick\_sherman

I see you edited, guess we’d need to see how saveHistory is constructed to work out the bottlenecks.

So basically it’s taking too long to save? But it’s not slowing down WHEN it saves, it’s slowing down progressively. By the time I have made like 30 moves it’s very slow, if I go on to 40 or 50 moves then it’s too slow to play.

[hasen6]

@anon63346430

First, comment out the save and confirm that you get no slow down - just incase.

Yes it’s fine all the way without the saving. And I confirmed with the edit above that’s in only the savehistory that is slowing the game down. Saving the other stuff causes no problem.

@remiduchalard

Do you need to save all at each move? Can you save only at game quit or finish or when the app is suspend ?

I could save on game quit but I’m not sure how to do that. It would have to save if the user was on the game screen (ie he did not return to the menu) double clicked the home button on iPhone and swiped to remove the game. That would be fine if that were possible but still it wouldn’t save if his phone ran out of power mid game.

[nick_sherman]

What’s the structure of saveHistory? How is it built?

The bigger and more complex the table, the longer json.encode will take to work. But it sounds like you’re experiencing low fps even after the save has happened? If you just drag objects around without actually making a successful move, is there lag?

[hasen6]

@nick\_sherman

What’s the structure of saveHistory? How is it built?

The bigger and more complex the table, the longer json.encode will take to work. But it sounds like you’re experiencing low fps even after the save has happened? If you just drag objects around without actually making a successful move, is there lag?

The first 10 moves the game is still responsive but it has already saved 10 times. The game just gets progressively slower so I don’t think it’s anything to do with encoding. The saves happen instantly with no wait at all.

But later on everything is slow. Which could be the encoding time taking longer and longer due to the data getting bigger and bigger.

The structure is like this:

 table.insert(saveHistory, { moveType = moveType, -- string ie "draw" etc data = data,-- contains various tables...could be the problem order = data.card.order, -- a number between 1 and 52 target = data.target.order, -- a number between 1 and 52 top = data.target.top, -- a number between 1 and 4 table = data.target.table -- a number between 1 and 7 })

EDIT: I can confirm it’s the data field that is slowing the game down. Commenting just that field out when saving the game eliminates the slow down completely. I guess I can have a look if perhaps some of what is in there doesn’t need to be saved.

[anon63346430]

@hasen6

The first 10 moves the game is still responsive but it has already saved 10 times. The game just gets progressively slower so I don’t think it’s anything to do with encoding. The saves happen instantly with no wait at all.

But later on everything is slow. Which could be the encoding time taking longer and longer due to the data getting bigger and bigger.

I am confused… if it was the encode>save that was slowing your game would just drop some frames and then carry on as normal.

Check your memory allocation and display object count in an enterframe and see if that yields any surprises.

Regarding saving, you can save on app suspend (this will get called in all but battery-died state changes).