So far VCMI savegame consisted of 3 files:
*vlgm1 with “common data” (gamestate, handlers and other lib stuff)
*vsgm1 with server-only data
*vcgm1 with client-only data
Now I changed it to:
*vcgm1 with commmon data + client data
*vsgm1 with common data + server data
What does that mean:
Desync issues won’t be solved upon loading. However I added a mechanism that automatically validates if common part is the same in both saves. That allowed me to find and fix some minor desync issues. Still, other ones remain. For now ignore the warning on loading. It’ll require bigger rewrite in objects.
It is finally possible to serialize pointers to lib stuff inside of client/server serialization procedures. That’ll help in many things. Particularly, saving AI state should be now relatively straight-forward to implement. (no more AI reset on load)
Is it possible to do something with Connection.cpp? Compiling it under gcc requires 1.5 Gb of memory - not a problem for me but for some users who compile vcmi from source (including such distros like Gentoo or Arch). Previously it was around 1 Gb but even that was much higher than any other file.
Seems to be coming from RegisterTypes instantiations.
That’s awful much. MSVC doesn’t seem to exceed 250 MB. It’s hard for me to do something here since I don’t have working GCC setup to check against.
I don’t see why RegisterTypes is so heavy on memory usage. For me it looks like pretty simple template, especially when compared to other monstrosities that happen in Connection.h when passing object to serializer.
You can try this:
Put there explicit template instantations for registerType against all used serializers. Make registerType DLL_LINKAGE
In Connection.cpp declare registerType as extern template to suppress instantiation.
If that works it should move the registerType instantiation burden from CConnection.cpp to RegisterTypes.cpp. Not sure if it’ll work, or if it won’t result in 1,5 GB compilation of RegisterTypes.cpp.
Some other random ideas:
replace boost type traits with std:: type traits — they can possibly use compiler intrinsics and be lighter. (I don’t know however if GCC 4.5 has that implemented — and has it better implemented than Boost)