Boost serialization performance.
I am rather new to Boost. I apologize in advance if I miss a protocol or
two in the group. Please correct me.
My group is considering using Boost for an application and some members have
expressed concern over the performance of Boost serialization because a
stack dump showed an excess of 100+ calls for a simple example shown below.
Is there a good resource that shows the relative performance of Boost
serializations?
Code example: (Windows XP, MSVS 2003) Around 389 bytes where serialized.
**example: (it's not pretty but it gets the job done)
void save_schedule(const bus_schedule &s, const char * filename)
{
std::ostringstream ss(std::ios::binary); // make an
archive
std::ofstream ofs("perf.txt"); // output
file
LARGE_INTEGER start, finish, diff, frequency; // windows junk
double duration; //
duration
char buff[256];
// adjust priority so high no one can interrupt!
SetThreadPriority( GetCurrentThread() ,THREAD_PRIORITY_TIME_CRITICAL );
// perform timed test
QueryPerformanceCounter(&start);
boost::archive::binary_oarchive oa(ss);
oa << s;
QueryPerformanceCounter(&finish);
QueryPerformanceFrequency(&frequency);
// compute results
diff.QuadPart = finish.QuadPart - start.QuadPart;
duration = ((double)diff.QuadPart)/(frequency.QuadPart) ;
sprintf( buff, "%f seconds\n", duration );
ofs<
Note that most if not all of these calls are inline functions which should be optimized away in release mode. So this has to beconsidered when evaluating performance. To date, no one has complained that serialization is a performance bottleneck. Having said that I 'm disappointed that there isn't more difference between relase mode and debug mode times on your tests.
I would be curious if someone wanted to make some tests which compare serialization (compiled in release mode with full optimization naturally) with just using normal stream output. I would expect that the time difference would be relatively small even though serialization is much more than just output.
I would also like to see the tests handle more data to get a better idea how things scale. Stream I/O and archive setup is probably larger than the actual i/o of less than 100 bytes. Basically, I believe this is a worthy effort and would like to expanded to be more informative.
Robert Ramey
"Graham"
participants (2)
-
Graham
-
Robert Ramey