Yeah as @dissociativity guessed, the save game long loading times appear to be caused by deserializing map memory from the save game data on disk - here’s a grab from the Android Studio profiler with the callstack:
It appears the short stall before displaying the surface level of the overmap is a similar issue - slow json read times for a large amount of data - seems serializing in monsters is taking the lion’s share, probably as there’s simply a lot of monsters:
I wasn’t able to get a capture of the quicksave lag before it exits back to the main menu, but I assume it’s a similar issue.
At a glance, I think a potential fix to this problem across the board might be to adjust the json data loading so that it always loads from a string buffer in memory (ie. the JsonIn class in json.cpp/h takes whatever std::istream object is passed into it in its constructor, immediately streams the contents of that stream into a std::string buffer in memory, then does the rest of its processing using a std::istringstream that reads from the string buffer) rather than operating directly on a fstream, since it seems file seeking using a std::fstream is causing quite a performance hit. Some of the code may already do this, but it would be great if it was default behaviour for all JsonIn streams. Not sure how much of an issue this is for the desktop version as file IO seems to be pretty fast, but wouldn’t be a bad idea for scalability and would definitely improve Android performance. At least I think that will work anyway.
Edit: just tried playing around with the solution I suggested above and it doesn’t seem to make much of a difference to load times unfortunately! I think IO streams are just rather slow in C++ across the board. Oh well, back to the drawing board.
