GCOM, was Re: Communicating with MICO

[Markus Stenberg]

Duncan Grisby <dgrisby at uk.research.att.com> writes:
> In article <slrn8a4h6i.uhd.kc5tja at garnet.armored.net>,
>  Samuel A. Falvo II <kc5tja at garnet.armored.net> wrote:
> [...lots of interesting COMishness...]
> >So the "sluggishness" that CORBA has amassed a reputation for is not the
> >fault of the spec, but of the individual ORB and B/POA APIs.  However, the
> >APIs do add an unnecessary layer of complication to the development of any
> >standards-compliant ORB.  And 2.3 just makes things worse.
> I'm interested in this "sluggishness". Do you have any experience or
> references to suggest that CORBA is sluggish in comparison to COM?
> Some CORBA implementations are quite slow (most notably Orbix), but
> others are not. I've just done a web search, and I can't find _any_
> speed comparisons of CORBA and COM; all of the COM/CORBA comparisons
> use other criteria. There are plenty of performance comparisons
> between different CORBA ORBs.

Well, okay, I'll bite the bullet and comment.. in terms of speed, fastest
ORBs are roughly twice the speed of COM and more that of DCOM (at least,
when using COM/DCOM with Python).

On example machine(r), the following (rough) speeds for synchronous
reliable event passing(*) were noticed between processes on same machine:

 NT
        com     => 3k msg/s
 Linux
        tcp     => 17k msg/s
        omniorb2 => 4k msg/s

On another machine using hp-sux, the visibroker orb was roughly 1/3 the
speed of omniorb2 in synchronous reliable calls. Oneway (asynchronous
unreliable) calls were in omniorb2's case roughly twice as fast, and in
visibroker's case thrice as fast as the synchronous ones, but omniorb2 was
still faster. (7k/2k sync, 13k/7k async in case someone cares)

(*)
        Meaning tcp roundtrip, or return value in the com/corba's
        case. These numbers are stolen from my master's thesis' appendix
        :-)

> As for API complexity, I agree that the CORBA APIs are unnecessarily
> awkward. However, the often-cited paper by Emerald Chung et al.
> 
>   http://www.research.microsoft.com/~ymwang/papers/HTML/DCOMnCORBA/S.html
> 
> implies that using COM from C++ is far more of a burden. I have no
> experience of COM programming myself, so I don't know how accurate it
> is.

COM is roughly as painful as CORBA, in my slight experience.

> Anyway, to get back on-topic for the newsgroup, using CORBA from
> Python cuts out the vast majority of the API ugliness. CORBA lets you
> do some fundamentally complex things, though, so there is bound to be
> some complexity in the API. For most things you can do with CORBA, the
> Python code is extremely simple. I assume the same is true for
> Python's COM interface.

Python's COM interface is much nastier than CORBA interface, IMNSHO. It
requires knowledge of lots of windows magic (*ids, different exection
models, etc) if you want to do serious stuff with it.

> Do you have a reference for GCOM?
> 
> Cheers,
> 
> Duncan.
> 
> -- 
>  -- Duncan Grisby  \  Research Engineer  --
>   -- AT&T Laboratories Cambridge          --
>    -- http://www.uk.research.att.com/~dpg1 --

-Markus Stenberg

-- 
Java leads to Javascript. Javascript leads to Shockwave. And Shockwave
leads to ... suffering.
	- ptomblin of /.