Bug 160

Summary:	Optimize InputCDR streams by remembering alignment.
Product:	TAO	Reporter:	Ossama Othman <ossama.othman>
Component:	ORB	Assignee:	DOC Center Support List (internal) <tao-support>
Status:	ASSIGNED ---
Severity:	enhancement
Priority:	P3
Version:	1.0
Hardware:	All
OS:	All

Description Ossama Othman 1999-07-26 18:35:56 CDT

he CDR streaming classes compute the alignment on each operation, but they could
remember the alingment from the previous insertion or extraction operation;
saving a few cycles but spending a little more memory.

Comment 1 Carlos O'Ryan 1999-08-03 12:08:59 CDT

This is a valid enhacement request, i'm marking it as accepted but their
implementation is deferred

Comment 2 Carlos O'Ryan 2000-02-28 11:36:59 CST

This bug was an enhacement request originally, but must be upgraded to a real
bug report.  Here is the long explanation:

- Consider a CDR encapsulation, they are marshaled as a sequence of octets
  into the containing CDR stream.  If the sequence is long enough TAO
  will avoid a data copy and simply chain the octet sequence as another
  element into the message block chain of the containing CDR stream.

- Now look at the overall alignment of the containing CDR stream,
  the first block on the stream starts properly aligned in memory,
  so its internal alignment and its memory alignment match.
  The same situation is true for the contained CDR encapsulation.
  But the CDR encapsulation may end on an 8-byte boundary in memory,
  while it is a 4 byte-boundary wrt to the start of the containing
  stream.

  To put numbers to this example, consider an encapsulation of 16 bytes,
  it would start and end on an 8-byte boundary.
  Assume the containing stream has 32 bytes so far, after inserting the
  encapsulation length the stream will contain 36 bytes, a 4-byte boundary.
  After adding the 16 bytes of the CDR stream it should also end on a
  4-byte boundary, but because the message blocks are only chained, and
  the contained stream is properly aligned in memory things don't work right.

  Naturally the numbers have to be much larger for the optimizations to kick
  in, but the same ideas apply.

Many thanks to Dennis Noll for tracking this down.

Comment 3 Carlos O'Ryan 2000-02-29 18:52:59 CST

The real bug has been fixed, look into this ChangeLog entry for details:
Tue Feb 29 16:40:43 2000  Carlos O'Ryan  <coryan@uci.edu>

What remains is to optimize the InputCDR stream, but i won't be able to work
in that for a long time, back to the common pool.

Comment 4 levine 2000-03-05 09:28:59 CST

Please assign . . .

Comment 5 Carlos O'Ryan 2000-03-13 10:13:59 CST

This is just a reminder for future optimizations.

Comment 6 levine 2000-03-18 07:42:59 CST

Accept, to be addressed later.