Martin Slater wrote:
//build oArch. Ebenezer: msgs.Send(buffer, lst); // where I didn't remove anything // from Send's implementation.
I think as you say, whether a flush gets embedded in the Send function should be configurable, but right now it just is. I'll admit it would be better if I didn't have to remove (#if 0) the end of the Send function, but I don't think that invalidates anything.
This I humbly disagree with, from a user point of view I would not want to patch either library to get optimal performance, If it is there and required then tests need to be done with it in. It would be simple to speed up boost.serialization by #if 0'ing out per class meta information lookups (versioning etc) but would still be extremely artificial.
Either way, with or without the embedded flush code, Boost serialization is less efficient than Ebenezer's Send in both tests. Today I timed how long it takes to build the two testcases mentioned in the original post on Nov. 8th. I used the date command so the numbers are only in seconds. list<int> list<int> and deque<int> ----------------------------------------------------------- Boost 42 61 ----------------------------------------------------------- Ebenezer 12 20
It would be interesting to see what the results are with a vanilla version of your library as well as a feature by feature comparision to see if you really are comparing apples to apples.
Both Boost and s11n.net support things like XML that Ebenezer doesn't. Boost in my opinion mistakenly tries to support "versioning." We don't and I don't think s11n does either.
Well since I use versioning heavily with boost.serialization this is a must have feature for me.
What happens if you want to change the type of an existing data member between releases - say from char to short? Brian www.webEbenezer.net