Re: [boost] [serialization]Boost.Serialization1.33.0BreaksSerializationCodeinDLLs

From: Kim Barrett (kab_at_[hidden])
Date: 2005-08-19 23:23:35

At 8:32 PM -0700 8/19/05, Robert Ramey wrote:
>Kim Barrett wrote:
>  > (As noted in another thread, I've run across
>  > some performance issues, which might be addressed by resetting and
>>  reusing archives, rather than constructing new archives all the time.)
>
>So, we have received only anecdotal data on where such performance
>bottlenecks might be.

Reset and reuse demonstrably helps; the question was why. And
Alex Besogonov <cyberax_at_[hidden]> wrote (15-Aug-2005):
>  I've managed to pinpoint the bottleneck: it's containers reallocations
>  of dynamic storage. Each time serialization is performed at least one
>  dynamic memory allocation for each container is neccessary.
>
>  If containers are reused then these allocations are performed only once,
>  because STL containers don't deallocate underlying storage in their
>  clear/reset/... methods.

That seems like more than anecdotal data...

>  > I'm pretty sure that intertwining runtime DLL loading with all of our
>>  clients of the serialization library is just not going to fly
>
>Note that as presentlly implemented an archive used for marshalleling
>something like IPC transaction would be a short operation - open archive
>with a string stream, serialize, close archive, send string to ipc
>connection.

And as noted previously, that approach of creating a new archive for each
marshalling operation has a significant performance impact.

>   My previous suggested solution of deriving from an existing
>archive class an adding would work very well in this case and be
>indistinguishable from a solution which built threading in at a lower level.

Even without the performance implications for creating new archives, this
would not be acceptable in our system. These IPC transactions are part of
a robot control system. We can withstand some fine-grained latencies due to
lock contention for synchronized data structures. Turning off the whole IPC
system for however long it takes to load a DLL is something else entirely.