Re: [boost] Updated performance resultsusing BoostSerialization 1.41

Subject: Re: [boost] Updated performance resultsusing BoostSerialization 1.41
From: Robert Ramey (ramey_at_[hidden])
Date: 2009-12-09 15:51:00

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