[omniORB] omniORB performance

[David Riddoch]

On Wed, 16 Feb 2000, Zeljko Rajic wrote:

> David Riddoch wrote:
> 
> > The point about operation names is that string compares are pretty darn
> > quick.  In most cases you can determine that two names a different just by
> > looking at the first character -- in most situations you are only going to
> > go through the whole operation name once.  You have to go through the
> > whole operation name at least once with hashing too (and at least twice if
> > you can't guarentee a perfect hash function), plus the hash lookup.
> 
> So does this mean that omniORB uses linear search (with strcmp) to find
> objects and operations?
> Asuming there are 1000 (or more) objects active (which shouldn't be
> esoteric), that would mean that it is necessary to make 500 strcmp calls
> in mean. Doesn't the hashing overhead amortize in such cases?

No -- object lookup is via hash table.  I'm just saying it would be a bad
idea to combine that with operation lookup, and that hashing for operation
names in general is not worth the effort, and in simple cases may make
performance worse.


> > Except for really esoteric cases it turns out that it is not worth the
> > effort.  I suspect the esoteric cases are only exercised in benchmarks
> > (such as really long operation names that only differ right at the end).
> 
> Yes, I agree with you concerning a single strcmp call. But isn't it a
> question how often a strcmp needs to be called to find the object?  At
> least I guess so.

strcmp is only an issue for operation lookup -- and as Sai-Lai pointed out
huge interfaces are a) rare and b) in need of re-design.


David