After noticing that the boost::serialization binary format is platform dependent recently some folks told me that I should maybe just use the text format for b::serial. The claims of relative efficiently being hard to tell came up of course. So this time I actually benchmarked with valgrind.
For text archive, 223,879,650 instructions and 2.97% overall runtime but using binary archive 2.1% relative runtime and 140,057,074 instructions. The relative runtime is for a short app interaction, not just application startup.
Since the b::ser is only used for loading data that is changed very infrequently but is loaded all the time I might end up having the text version as a fallback just in case you change architectures libferris can try to load the binary version, fail and then try to load the text version and force a resave right at that point. This means loading after an architecture switch will be about 5-6 times slower, but only the first time you run any libferris app after the arch change.
Fun to look ahead to the maemo / moko invasion of the ferris.
I added a few little optimizations here and there to libferris for the next release too. Many of these make the filemanager more responsive in some use cases I have... YMMV.