I've just added looped live code editing to my source. It is functional, but has the following issue:
When I hit 'L' to start recording, the program consistently hangs for 10 full seconds before proceeding (I know this because I can hear the sound buffer loop 10 times). This consistency makes me wonder whether it's an issue with how I'm accessing the file, rather than the performance of my machine.
I've confirmed that the culprit is the call to WriteFile:
Adding a watch to BytesWritten shows that this call is writing 1,140,850,688 bytes (which is correct for 1 GB permanent storage plus 64 MB transient storage).
I understand that this is a synchronous file access and we should expect a fairly high wait time, but 10 seconds? Consistently? It takes a lot less time for Casey on the stream.
Prior to the GameState write to file, I use the following call to create the file and point the handle to it:
Many thanks in advance for your thoughts.
When I hit 'L' to start recording, the program consistently hangs for 10 full seconds before proceeding (I know this because I can hear the sound buffer loop 10 times). This consistency makes me wonder whether it's an issue with how I'm accessing the file, rather than the performance of my machine.
I've confirmed that the culprit is the call to WriteFile:
1 | WriteFile(Win32State->InputRecordHandle, Win32State->GameMemoryBlock, BytesToWrite, &BytesWritten, 0); |
Adding a watch to BytesWritten shows that this call is writing 1,140,850,688 bytes (which is correct for 1 GB permanent storage plus 64 MB transient storage).
I understand that this is a synchronous file access and we should expect a fairly high wait time, but 10 seconds? Consistently? It takes a lot less time for Casey on the stream.
Prior to the GameState write to file, I use the following call to create the file and point the handle to it:
1 | Win32State->InputRecordHandle = CreateFile(PathName, GENERIC_WRITE, 0, 0, CREATE_ALWAYS, 0, 0); |
Many thanks in advance for your thoughts.
Casey has faster machine and/or hdd :)
In day 25 he improved how replay data is stored on disk, and it was a bit faster. Take a look at that.
In day 25 he improved how replay data is stored on disk, and it was a bit faster. Take a look at that.
Thanks for your help.
It seems your guess is correct. I found a benchmark of my hybrid drive that shows it's slow for large sequential file I/O: ST1000LM014 Benchmark
By "replay data", do you mean the GameState specifically? When I only record the input and not the GameState, there's no long wait.
In any case, hopefully this will be resolved/mitigated when I've completed HH day 025.
mmozeiko
Casey has faster machine and/or hdd :)
It seems your guess is correct. I found a benchmark of my hybrid drive that shows it's slow for large sequential file I/O: ST1000LM014 Benchmark
mmozeiko
In day 25 he improved how replay data is stored on disk, and it was a bit faster. Take a look at that.
By "replay data", do you mean the GameState specifically? When I only record the input and not the GameState, there's no long wait.
In any case, hopefully this will be resolved/mitigated when I've completed HH day 025.
By "replay data" I mean everything that is saved to disk - state and inputs.
At the moment, we're not actually using most of that 1GB of game state, so you could just change it to write less data.
joeld42
At the moment, we're not actually using most of that 1GB of game state, so you could just change it to write less data.
Right. I am doing this temporarily - but it's a band-aid, not a fix.
I'll post here if day 025 doesn't help the issue.