[omniORB] omniorb and omniorbpy speed

[Duncan Grisby]

On Tuesday 28 November, Timothy Docker wrote:

> These times are quite repeatable. Comparing the local (user) cpu
> times, the omniorb C++ times are about 3 time slower than Orbacus,
> and, more significantly the omniorb_py times are 4 times slower
> again. Is omniorbpy slow when dealing with anys?

As Sai-Lai says, you should compile omniORB and omniORBpy with Sun CC
to make it fair. I'm mainly surprised that omniORB C++ is so much
slower than ORBacus. Every comparison I've ever seen shows omniORB to
be faster. I assume that you are using an ORBacus server. Are the
tests performed on a single machine?  If so, ORBacus might be using a
shared memory or Unix domain socket transport, so that would explain
the difference.

Anyway, I suspect that there are two reasons for omniORBpy being
slower than omniORB C++. First, Python is just slow. Building Python
objects takes a lot of time.

Second, and probably more significantly, omniORBpy fully unmarshals
the contents of an Any when it is received, whereas omniORB C++ (and I
assume ORBacus) keeps the marshalled form in memory, and unmarshals it
when you extract the value from the Any. So omniORBpy is doing an
awful lot more marshalling work than omniORB C++. I suspect that if
you modify the C++ client to actually extract the Anys' contents, the
times will be much more similar.

This seems like a reasonable thing to do, since in most circumstances
you will be using the majority of Anys you receive. Even something
which just receives Anys and passes them on, like an event service,
has to unmarshal the Anys and remarshal them in many cases. The only
time omniORBpy's behaviour is bad is when you are receiving a very
large number of Anys, and immediately throwing most of them away
without looking at them.

C++ ORBs would quite possibly use the same scheme as omniORBpy if only
the C++ type system allowed it.

Cheers,

Duncan.

-- 
 -- Duncan Grisby  \  Research Engineer  --
  -- AT&T Laboratories Cambridge          --
   -- http://www.uk.research.att.com/~dpg1 --