[omniORB] performance penalty from the interface nature?

[Brenneis, Steve]

I have seen some interesting "hacks" used to get around perceived
performance issues related to this subject. DEC used to have a product
called Object Broker (not very imaginative, don't you think?). In that
product, they generated a UUID (Universally Unique Identifier) for each
method and used it in the request invocation. Since the UUID was over one
hundred bytes long, I hardly think they gained a performance boost over
passing a method name, say, for instance, "getName," by string. I can't
really see how indexing or hashing method names could gain a performance
boost over a simple sequential string comparison within the scope of as many
as a few dozen methods in a typical interface. This is especially true when
one considers the capabilities of most C++ compilers to optimize machine
code.

> -----Original Message-----
> From: Haarek Ryeng [mailto:Haarek.Ryeng@datarespons.no]
> Sent: Wednesday, October 18, 2000 3:23 AM
> To: omnilist
> Subject: [omniORB] performance penalty from the interface nature?
> 
> 
> I assume that the functions in an interface would have to be 
> indexed in some way for the servant to execute the right method.
> 
> How is this done in OmniORB 3.0? Is there a performance 
> penalty by using long function names (if string indexed)?
> 
> Does anyone have a pointer to info about the protocol 
> overhead introduced by the ORB?
> This is often an issue in embedded systems were people are 
> skeptic to all introduced overhead, and it would be nice to 
> have some hard facts for discussions ahead (I'm pro
> ORB btw).
> 
> --
> 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)
> 
> 
>