[omniORB] omniorb and omniorbpy speed

[Duncan Grisby]

On Wednesday 29 November, "Renzo Tomaselli" wrote:

>     what about dealing with (possibly long) sequences of atomic types in
> Python ? OmniORB 3.0 has been optimized for that when a any/dynanys is
> involved (I raised this issue sometime ago because image handling through
> anys was painful with 2.8).
> Now what about Python performance, with such sequences both alone (in/out)
> and inside anys ?

Unfortunately, Python can't be so quick in almost all circumstances. A
Python list or tuple is stored as a PyObject structure containing a C
array of pointers to other PyObjects. Each of the objects in the array
contains type information and other things, as well as the actual
value. So, a list like [ 1, 2, 3, 4, 5 ] actually consists of six
PyObject structures. To send it as a CORBA sequence<long>, for
example, involves looking at those six objects individually. Not much
scope for optimisation.

Sequences and arrays of octets and chars map to Python strings. Those
are stored as a PyObject containing a simple C char* buffer, so they
are transmitted in one big lump. When code set negotiation comes along
it will clobber char performance, but octet will always be fast.

So sending things as sequence<octet> is fast, whether alone or inside
an Any, but essentially everything else is slow. Python is good for
many things, but performance isn't one of them.

Cheers,

Duncan.

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