Cocos version this topic is relevant for:
auto ud = UserDefault::getInstance();
ud->setIntegerForKey("key1", ud->getIntegerForKey("key1") + 1);
ud->setIntegerForKey("key2", ud->getIntegerForKey("key2") + 1);
ud->setIntegerForKey("key3", ud->getIntegerForKey("key3") + 1);
ud->flush(); // irrelevant
This piece of code parses the xml file, then retrieves the value for
key1 and then destroys the xml document in memory. Now we add 1 to the returned value,
setIntegerForKey again parses the xml file, adds or modifies the value for the key
key1, writes from memory to disk and then destroys the xml object in memory. Now we do the same 2 more times.
Overall the entire xml with all its elements is parsed and built in the memory 6 times, destroyed 6 times, and written to the disk 3 times.
With keeping the xml representation (could be
ValueMap) persistantly in memory, all this can be easily done with just one write to the disk (after calling a proper flush, which is now defined empty in most platforms). The underlying logic is already there, implemented in Cocos, with
I have already solved this for my own project similar as to how I’ve described above, but there must be thousands who have their games slowed down by constantly doing unnecessary calls to the OS, doing expensive parses and whatnot, even to read data not even to write.
Now I’ve discovered that steps have been to heal this thing, in
CCUserDefault-android.cpp for example there is code already that hooks into java code which is supposedly much more efficient; in iOS code similarly. However these are not called because a macro is defined:
KEEP_COMPATABILITY. Can a dev tell us about what it means please and when its removal is due?