[omniORB] Quadratic behavious of omniORB DSI

[Victor Joukov]

I found the cause of this behaviour. Correct me if I am
wrong.

The cause is twofold: first is the internal representation
of Any, which is just CDR in native byte order. It
minimizes efforts when (un)marshalling it, but combined
with cdrMemoryStream::reserveOutputSpace, which for sizes
larger than 1024 actually reallocates linearly this leads
to quadratic reallocations for large, complicated objects.
Complicated (aka nasty) are ones, whos size can not be
easily predicted.

So fix can be applied to any of these points: unrealistic
rewrite of Any, which can store tree structure instead of
wire format (I suspect TAO went this way) or sacrificing
memory by always reallocating in exponential manner (which
leads to linear amortized time).

Victor.

>From:  Victor Joukov <vic@rambler.ru>
>Subject:  [omniORB] Quadratic behavious of omniORB DSI

>I tried to benchmark relative performance of static sever
>implementation versus DSI. For a simple interface:
>
>interface SomeInterface
>{
>  struct SomeStruct {
>    sequence<string> ss;
>  };
>
>  void set(in SomeStruct s);
>};
>
>the difference between behavior is not percents, but the
>order of complexity. I have empty implementation for both
>servers, that is they do not do anything with the data,
>just accept them. I fill stings with letters 'A' 100 times
>and send various number of these strings packed in struct
>to server. I repeat this procedure 100 times to measure the
>time more accurately.
>
>The results are (in seconds):
>nObjects DSI     static
>1000     2.02    1.03
>2000     11.95   2.97
>3000     31.99   4.93
>4000     62.98   6.00
>5000     111.99  8.97
>
>I use omniORB 4.0.0 on Windows. The server and client are
>run on the same machine. Did anybody face with this kind
>of behaviour?
>
>Thanks in advance,
>Victor.

---------
Рамблер желает всем счастливого Нового Года!!!
http://www.rambler.ru/