Currently the ORB performs data copies that could be eliminated. For example,
when sending a large sequence of longs the data could just be added to the
chain of message blocks.  This optimization is currently in place for octets,
but not for other basic data types.
On the demarshaling path some similar optimizations could be applied, but here
the situation is more complicated: the memory allocated for the CDR stream can
be allocated on the stack or TSS storage.  Whatever optimizations we use must
be limited to the case where the memory is only used in the current thread
activation, and does not survive the upcall to the application.
With octet sequences we use reference counting on the CDR message block, and
provide transparent extensions to the octet sequence implementation that
handle that reference count.  Unfortunately this technique will not scale,
and suffers from a number of problems, for example, when used in conjunction
with TSS allocators: the application could try to release the octet sequence in
another thread, leading to corruption in the TSS allocator.
A more promising approach is to:
- Inform the CDR stream if the memory it contains can be used in other threads,
  that info can be used to disable "dangerous" optimizations automatically.
  This is also useful in the buffered oneways case, to minimize data copying
  when the message is buffered.
- When demarshaling sequences it is possible to create the sequence without
  ownership of its data, just pointing to the CDR stream.  But this is only
  applicable if:
  + The CDR stream is alive during the upcall to the application.
  + The sequence is only used as an 'in' parameter.
  I'm not sure how to detect this case, but it could be an important way to
  improve the demarshaling time.
- When demarshaling Anys we perform several data copies, but finally the data
  is stored as a CDR stream to be demarshaled in the >>= operator.  Those
  copies could be optimized, but all the problems with TSS or stack allocated
  memory crop up again.