Dario FF, on 16 May 2012 - 01:32 PM, said:
I believe this tool's logging mode has been the cause of many stability issues, since I've disabled it and I got rid of:
- Endless loading when quitting the stages
- Varying performance when playing the same stage again(increased pop-in and loading times)
Weird, I've never had any of those issues. But my system is fairly fast and very stable.
It's widely known that printing to the console can be a source of lag for repeated operations(even more for a game that streams from the disk constantly),
Do you have any sources for that? Never heard anything of the sort.
But yeah, if you print a ton of text to the console window, I guess it could slow things down, depending on how fast those console text output functions by Windows are.
so my question is, is CPKREDIR's process in the same thread? How does the logging work that it could be causing these issues? It could just be luck and I'm drawing false conclusions, but since I've disabled it the game's been running much better for me.
Sonic Generations has a bunch of threads, over a dozen, I think. CPKREDIR gets called by a CRI file loader thread that handles read requests by other threads, which will wait until the requested data has been retrieved.
If you do grab the scrollbar thumb of the console window, or select text in it, then you WILL stall CPKREDIR's thread, which is the mentioned loader thread, and this will of course stall the thread that is waiting for the read request to finish. But if you leave the console window alone, it shouldn't be a problem, or so I thought at least.
Funny thing is, even if you disable logging (LogType=0), CPKREDIR still performs exactly the same steps, that is preparing the logging messages, except for the final write to console or write to file calls. Yeah, I could obviously optimize that (don't waste time on building strings if they aren't output in the end), but I haven't gotten around to it yet. So, if disabling the console actually helps with your issues, then the problem aren't my logging routines but rather the output. Maybe console writes really are too slow. Have you checked if logging to file (LogType=2) has the same issues as the console? That'd be interesting to know. There's also an undocumented LogType=3 setting, which uses the OutputDebugString WinAPI function.
In any case, could you provide the default option in the INI as not-logging if it turns out to be the problem?
Sure, that was my intention for the "finished" version anyway. But for these early releases, I thought it would be better if people had some immediate feedback whether CPKREDIR was actually running or not, via the console window.