COM/CORBA/DCOP (was: Hello people. I have some questions)

[Alex Martelli]

"Paul Rubin" <phr-n2001 at nightsong.com> wrote in message
news:7xelpo86rj.fsf at ruckus.brouhaha.com...
> "Alex Martelli" <aleax at aleax.it> writes:
> > > I don't know why people would consider CORBA too heavyweight for
> > > connecting desktop apps -- the few performance comparisons between COM
> > > and CORBA I have seen show CORBA to be as fast or faster than COM.
> >
> > For *in-process* interaction?!  There's something askew here... I
    ...
> As I remember, there are two ways to use COM in-process.  One is to
> use the regular dispatch method which does a dictionary lookup.  The

This is normally called "Automation" and works for either in-process
or out-of-process COM (but NOT particularly fast in either case:-).

The interpretive overhead is VERY substantial in this case, of course:
it's not just about looking up the name (that may be done once,
then the returned numeric ID can be used as an index in a table --
pretty good amortized efficiency), it's mostly about marshaling
the arguments (they DO have to be marshaled, since the Invoke call
of the IDispatch interface cannot accept "a generic stack frame" --
it wants an array of VARIANT's, so SOME code, typically somewhere
in the OLE runtime, must be marshaling
    stackframe->array of VARIANTs->stackframe
and THAT is the part that normally dominates, except perhaps
on argument-less methods using optimized non-interpretive custom
marshaling for the purpose).

> other way is to use a static index to get to the method.  The second

I.e., basically a vtable-based C++ call (there's a tiny implementation
difference on Win32 -- C++ puts 'this' in register CX, while a COM
call pushes it to the stack -- that's over a machine-cycle worth of
overhead in typical cases, as I measured things).

> through a dispatch vector.  I don't see how interacting with a CORBA
> ORB can be nearly that fast.  However, the dispatch method might end

I think the way the Corba semantics used to be specified (not sure
if that changed over the last few years) there just *has* to be
more overhead in Corba -- at the very least, a proxy object that
sits between client and server relaying things back and forth and
providing some semantically-mandated argument-treatment.  I would
be astonished to see that supplied for less than TEN machine
cycles in typical cases -- almost an order of magnitude more than
the COM minimal-overhead of about one machine cycle.  "As fast
or faster than COM" is still an astonishing claim to me.

If they changed the Corba semantics to allow for faster inprocess
interaction, or, as some poster suggested, "Corba" vendors have
ways to let you interact while deliberately *violating* the
rigid prescribed semantics, then I guess overhead could indeed
be lesser.

Note that I'm NOT claiming a typical overhead of (e.g) ten machine
cycles per method-call would be a problem at all, in most cases -- I'm
just questioning that still-crazy-sounding-to-me "as fast or
faster" claim:-).


Alex