[omniORB] performance penalty from the interface nature?

[David Scott]

Hi,

On Wed, 18 Oct 2000, Haarek Ryeng wrote:

> I assume that the functions in an interface would have to be indexed in 
> some way for the servant to execute the right method.
>
If you run the idl compiler and look in the SK.cc file, inside the
_impl_I::_dispatch method you can see the code which looks up the correct
function given its on-the-wire operation name (a string).

> How is this done in OmniORB 3.0? Is there a performance penalty by using 
> long function names (if string indexed)?
> 
Operation names are sent as strings on-the-wire in GIOP. Dispatching the
call to the right method is done using a simple series of string compares.

Performance has been discussed on the omniorb-list before, for example in
the thread:
  http://www.uk.research.att.com/omniORB/archives/2000-02/0152.html

Quoting from Sai-Lai:

> ...
> There seems to be a general believe that doing sequential string
> matching to match an operation name with the upcall routine is
> inefficent and "high performance" ORBs should do something like hashing
> or binary tree search. We did some measurements and find that simple
> string match is actually faster for small number of operations defined
> in an interface. The  picture reverses as the number of operations
> increases but the yield point  is at least tens of if not over 100
> operations. It seems to me it is hard to find in real use an interface
> with over 100 operations or else it is a really fat interface that can
> do with some weight loss exercises. 
> ...

Of course, if you were _really_ concerned about such things you could
modify the stubs by hand, but you would have to be careful. Also
you could implement your own on-the-wire protocol (an Environment-Specific
one) for your specific needs, but it wouldn't of course be interoperable
with normal servers.

HTH,

David