From: Robert Ramey (ramey_at_[hidden])
Date: 2006-09-21 18:18:53
Matthias Troyer wrote:
> On 21.09.2006, at 16:34, David Abrahams wrote:
> Robert, you did not have any complaints on June 4th, but just asked
> me to add our optimizations directly to your binary archive.
Its entirely possible I might have suggested this without correctly
envisioning what the final result would look like.
uhhh - that happens to me all the time. I suppose that's why
I'm a software developer as opposed to say ... - a diamond cutter
or suicide prevention counseler.
> If you
> feel more comfortable without this, we can undo this at any time
> since it will not break any existing archives. If however, as you
> write, you feel you can live with what we have done then we can leave
> it as it is and I can certainly take over responsibility for
> maintaining the array optimizations and any further extensions to it
> that might be desired.
That's fine with me - really.
My concern is that the maintainence and support of this has been
underestimated. Personally I've found the code very hard to follow.
However, It's not a big issue for me now that you've offered
to do it.
At the risk of picking at a festering sore - here is my (imperfect)
recollection of how we got here.
The original proposal required adding save_array to all present and
future archives. I objected to the idea of expanding the interface
just to accomodate a special case. This was resolved with the
"array_wrapper" which provided an overridable default which
was suitable for "other" archives. This was a HUGE improvement
as far as I was concerned.
As things progressed, it became clear that support for"serialization
- including the new array_wrapper - needed to be generalized
some in order to remove direct dependency of the serialization code
on certain specific types (such as nvp and array, and C++ arrays).
This you did - Another significant improvement.
So now we have a specific wrapper (array_wrapper) handled in a
specific archive binary_archive. This is analogous to the situation
in xml_archive where nvp is handled in xml_archive. (Its not quite
the same - as xml_archive without nvp really makes no sense.)
To me the current implementation stops short of carrying the
wrapper idea to its logical conclusion. - having the binary archive
code independent of array_wrapper (or any other particular wrapper
for that matter). This is in line with my (mostly successful)
campaign to keep archive code independent of particular data types.
I also believe that things have been confused by an evolution
in the original idea for save/load array. As I remember the motivation
was that save/load array could be re-implemented differently for
binary and/or mpi and/or other archives. Of course we have this
now as the array_wrapper can be implemented differently for
each archive. But now it seems that save/load array are going
to be quite different for binary and mpi type archives. I think that
at one point there might have been the idea that save/load implementations
could be shared between different binary-type archives. But now
it seems that binary_archive an mpi and/or other archives will have
less in common than originally thought.
I think this evolution has led to code which is very hard for me to follow
and which will be more work to maintain and support. I can't help
but think that if 10x speed up of binary_archive were considered today,
(given the wrapper and other changes), the enhancement would
be less general and much simpler.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk