Boost logo

Boost :

Subject: Re: [boost] Updated performance resultsusing BoostSerialization 1.41
From: Robert Ramey (ramey_at_[hidden])
Date: 2009-12-07 19:08:28


Kim Barrett wrote:
> On Dec 7, 2009, at 12:29 PM, Robert Ramey wrote:
>> I'm aware of this suggestion and it's motivation. I'm not
>> convinced that this is the best way to address.
>
> I'd be happy to discuss alternatives.
>
>> In your particular application, I don't think it should be necessary
>> to "reset" the archive as long as you're not serializating any
>> pointers. If one is not serializing any pointers, then no
>> tracking is done. So a "reset" operation should be surperfluous.
>
> I hadn't realized that archive reuse might already be an option when
> there's been no pointer tracking. (Of course, that probably also
> requires that one is using the boost::archive::no_header option, but
> that is true for my use-cases where this performance issue is of
> concern.)
>
> That restriction of no pointer serialization is not met by my
> application. Serialization of pointers isn't common, but some of the
> data types being serialized are complex and do include pointers, and
> in some cases may be polymorphic and serialized via base pointers. It
> might be possible to tag the complex types in some fashion though,
> and do archive reconstruction when dealing with those. Or it might be
> possible to detect that complex case has been encountered (by peeking
> inside the archive) and force a reconstruction on next attempt to
> reuse. I will add this to my notes about this issue, to think about
> some more when I finally find some time for it.

The "real" solution which I envision is just to suppress tracking
in an archive. I've considered different syntaxes for doing this
and the best way to implement this. serialization of rvalues
also touches on this subject so the best way to do this isn't
as obvious as it might seem to a casual user.

If such facility were implemented, one would proceed
something like this.

create an output stream. This would not be a file
stream but rather be plugged into a communication channel.
If asio doesn't have something like already, I'm sure a
"channel_buffer" would easily be crafted. Open
this stream and connect to the other application.

Then open the archive using this ostream as an
argument. On the other side of the channel open
an archive using an istream (with this channel_buffer type).

Then your in business !!. The sending side just uses
the << operator to send any data it want's while
the other side just uses the >> operator to reconstruct
any data sent. Easy as pie !

So, to my way of thinking, that's the real solution.

Robert Ramey


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk