Re: [boost] Updated performance resultsusing BoostSerialization 1.41

9 Dec 2009

      Kim Barrett wrote:
...
On Dec 7, 2009, at 7:08 PM, Robert Ramey wrote:
...
...
So, to my way of thinking, that's the real solution.
While that is an interesting solution to some problems, I don't
think it actually helps with my use-cases (multiple).
As mentioned earlier, turning off pointer tracking is not an
option for me in some cases. I can envision various ways to deal
with that. If one had a means for determining whether serializing
a data structure used or would use tracking one could use this
approach now, with no [further] changes to the serialization
library.
However, none of my existing use-cases are stream oriented. They
are instead all transaction / packet oriented. This means there
needs to be a clear boundry, where all output to be generated by
the archive has been flushed to the buffer collecting the data,
any "end of archive" data needs to be written, and the next
transaction / packet needs to include any "beginning of archive"
data needs to be written again. Right now I'm accomplishing that
by deleting the old archive and creating a new one. I'm looking
for either a lighter weight alternative to that (preferably), or
a way to make that delete / recreate lighter weight.
Hmmm - Faced with this,

struct transaction {
    transaction(data1 &d1, datad &d2, ....)
    // or
    transaction(data1 d1, data2 d2, ...)
    template<class Archive>
    void serialize(Archive &ar, const unsigned int version){
        ar & d1;
        ar & d2;
        ...
    }
};

I would think the most natural solution would be:

So on the sending side:

main(.){
    tcpostream tos;
    text_oarchive oa(tos)
    loop(){
        transaction(d1, d2, ..) t;
        oa << t;
    }
}

And recieving side

main(.){
    tcpistream tis;
    text_iarchive ia(tis)
    while(tis.open()){
        transaction(d1, d2, ..) t;
        ia >> t;
    }
}

The only fly in this ointment is that tracking will imply that
only the first transaction data is actually sent.  So to
implement this - only tracking has to be surpressed.

This is related to the issue of serialization of r_values
which conflict with the idea of tracking in a fundamental
way.  If this were addressed one could just use

oa << transation(d1, d2, ..)

This would be pretty efficient in that all the class
information would be sent only once.  Note
that MPI also has a special archive for this sort
of stuff you might want to check that out.

Robert Ramey