[omniORB] performance penalty from the interface nature?

[Haarek Ryeng]

Thanks for your responses Guys! (David S. and Steve B.)

I aggree that string comparing is as good as any hashing, or such, under normal circumstances. Besides, CPU horse-power is cheap!

The thing I'm worried about is communication performance. Sometimes communication links in industrial embedded systems can suffer serve degradation in quality over periods
of time, going as low as 1200 bauds when the normal would be several MBits/sec.
But then again, if you save 10 characters (bytes) in a function name (I've yet to check that dispatch method David) I guess it would drown in the TCP/IP/IIOP/GIOP header
overhead anyway! Oft times I find applications spending most of their time communicating.

A plug-in environment specific protocol to wrap the GIOP "directly" on-the-wire would probably do the trick. But it is not a tempting task to undertake!

- Haarek -

David Scott wrote:

> 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

--
Haarek Ryeng
Senior Software Development Engineer
Data Respons AS, 1/50 Wolfe St,2300 Newcastle, NSW, Australia
Phone: +61 2 49261137 / +61 4 17421966 (work/mobile)