Re: [boost] [serialization] fast array serialization (10x speedup)

From: David Abrahams (dave_at_[hidden])
Date: 2005-11-25 09:47:26

"Peter Dimov" <pdimov_at_[hidden]> writes:

> David Abrahams wrote:
>> "Peter Dimov" <pdimov_at_[hidden]> writes:
>>
>>> ("Archive" implies persistency, and relying on a specific
>>> memory layout is not a way to achieve it.)
>>
>> I think Robert's statement
>>
>>  "Here, we use the term "serialization" to mean the reversible
>>  deconstruction of an arbitrary set of C++ data structures to a
>>  sequence of bytes. [...]
>
> Robert's statement is not at odds with what I wrote above.

What you wrote above implies additional constraints not present in
Robert's statement.  He doesn't say anything about persistency.  I can
think of many useful Archives that don't "persist" in any meaningful
way.  Whether those correspond to your notion of the word "archive" is
another matter.

>>> If you have such an archive, you can add an overload SFINAE'd on
>>> is_bitwise_serializable
>>
>> Robert wants portability to vc6, which doesn't support SFINAE.  I
>> doubt he'd want to accept a change that, to be practically taken
>> advantage of, would require users to apply SFINAE.
>
> On VC6 you can use separate overloads.
>
> I have the feeling I must be missing something fundamental. :-) 

Me too.  It certainly seems as though you -- most uncharacteristically
I might add -- jumped into this conversation and made many statements
without due consideration.

> What do you perceive as the important difference between providing
> an optimize_array overload that returns mpl::true_ and providing a
> save_sequence overload that calls .save_array? (Except that the
> latter is obviously more flexible.)

It's not a major difference; I have merely been giving rationale for
our choices and preferences.  In short:

  a. Less code to write and fewer opportunities to make mistakes.  Not
     a big difference, but a difference nonetheless.

  b. The ability to use a base class to implement common
     functionality.  That's useful when accomodating Robert's desire
     not to modify his existing library code in any way, if you want
     to avoid duplicating support for std::vector and builtin arrays.

In short, your simple proposal would, I think, be a major improvement.
However, it is incomplete, it doesn't address Robert's constraints,
and it imposes a bit more work than necessary on archive authors.

-- 
Dave Abrahams
Boost Consulting
www.boost-consulting.com