[omniORB] Performance of Sequences

[Sai-Lai Lo]

David,

omniORB is particularly efficent to transfer bulk data in the form of a
sequence of basic types, e.g. sequence of octet. In fact for your example,
it will transfer the whole sequence in one send() call directly from your
buffer and receive with a single recv() call directly into the receive
buffer on the client side. You can't get more efficent than that.

When reporting a problem, it is important to say what version of omniORB,
what platforms are your programs running. 

For instance, are you using omniORB 3.0.0, 2.8.0 or 3.0.1?  If you are
using the unpatched 3.0.0 on NT, you are affected by the bug no. 16
reported here:

http://www.uk.research.att.com/omniORB/bug300.html

This bug is also one of the main reason to do a 3.0.1 release, as I have
said in my posting last week.

I've run your test on Solaris<-->Windows 2000 with 3.0.1, the test takes no
time to complete.

Sai-Lai


>>>>> David Sansom writes:

> Thanks for your suggestions. I have moved to the octet sequence but this hasn't made any difference. This is the skeleton code that I am using for the client / server : (server on Solaris, client on NT)

> The IDL is:
> interface Fred
> {
>   typedef sequence<octet> ResultSet;

>   long ginger(in string strSql, out ResultSet results);
> };

> With the server-side implementation as:

> long FredImpl::ginger(const char * strSql, ResultSet * & results)
> {
>   long lBufSize = 100 * 1024; //Some big buffer

>   //Create a buffer
>  CORBA::Octet * pbuf = Fred::ResultSet::allocbuf(lBufSize);

>   // Fill buffer with something eg results of underlying db query
>   ...
>   //

>   //Create sequence using buffer (passing ownership)
>   results = new Fred::ResultSet(lBufSize,lBufSize,pbuf,1);

>   return lBufSize;
> }

> On the Client side:

> ...
> ResultSet * prs;
> CORBA::Long l = objFred->ginger("Some Sql",prs);
> ...

> My example timings give 7 secs for the client-side objFred->ginger() call, whilst the server spends around 3 secs within the Fred::ginger() implementation. The remaining 4 secs is spent transmitting & marshalling the return sequence.


-- 
Sai-Lai Lo                                   S.Lo@uk.research.att.com
AT&T Laboratories Cambridge           WWW:   http://www.uk.research.att.com 
24a Trumpington Street                Tel:   +44 1223 343000
Cambridge CB2 1QA                     Fax:   +44 1223 313542
ENGLAND