"Re: serialization performance"
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
On Mon, 14 Nov 2005 22:24:41 00100 (CET), bwood <brass@mailvault.com> wrote:
Either way, with or without the embedded flush code, Boost serialization is less efficient than Ebenezer's Send in both tests.
What are we comparing here? You really need to give the Boost commuinity more visibility into your code if you expect your arguments to be taken seriously. There is nothing on http://www.webebenezer.net that resembles documentation or a complete test application that can be compiled. 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
Compile time is generally not the reason folks choose one library over another. These decisions are generally based on features.
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?
You'd probably need to implement split save and load methods. The load method would check the version number and (if old) read a char and put that value into the member which is now a short. // new code struct myclass { short m_data; ... template<class Archive> void load (Archive& ar, const unsigned int version) { if (version > 1) { char c; ar & c; m_data = static_cast<short> (c); } else { ar & m_data; } } }; This is pretty simple assuming you're just widening the type to hold a larger range of data, but if your'e changing the sematics, you'll clearly need more code to interpret the old-style value and store it in your new-style member. None of this is rocket science though. -- Caleb Epstein caleb dot epstein at gmail dot com
On 11/14/05, Caleb Epstein <caleb.epstein@gmail.com> wrote:
template<class Archive> void load (Archive& ar, const unsigned int version) { if (version > 1) {
... That should be "if (version < 1)" -- Caleb Epstein caleb dot epstein at gmail dot com
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
Well that is well within the realms of local optimisation, orders of magnitude would be worrying. I do know there are performance issues with Boost.Serialization, only a month ago I implemented a faster binary archive to address some of these problems with massive gains in some scenarios. What I disagree with is that these problems are necessarily architectural. Having spent some time examining in a reasonable amount of detail the performance of Boost.Serialization in vtune I'm pretty comfortable that there are some serious gains to be had. Robert has also recently started an effort towards profiling and tuning the library so there is effort being put into it. Without a feature by feature comparision of libabries its hard to tell what is being compared, lack of versioning for me would put your library out the window for many of my tasks and there would have to be an extremely compelling advantage to use a different system for the other areas.
What happens if you want to change the type of an existing data member between releases - say from char to short?
Then I split the load and save into seperator functions and in the load write something like template<class T> void load(T &ar, int version) { if(version > whatever) { char val; ar & val; m_short = val; } } adding new members to the class is similarly simple. Some of our file formats are in a constant state of flux as we proceed through development, the current time to rebuild all assets is over 3 hours and growing daily, without versioning this would be fatal. cheers Martin -- No virus found in this outgoing message. Checked by AVG Free Edition. Version: 7.1.362 / Virus Database: 267.13.0/168 - Release Date: 14/11/2005
participants (3)
-
bwood -
Caleb Epstein -
Martin Slater