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

[Alex Martelli]

"Neil Hodgson" <nhodgson at bigpond.net.au> wrote in message
news:yqel7.13971$bY5.81637 at news-server.bigpond.net.au...
> Alex Martelli:
> [about Automation]
> > ..., 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).
>
>    At the risk of being pedantic (and with Alex, it is *such* a temptation
> :-) ), you can write your automation code (both client and server) to deal

If you have control of both client and server, yes, but then there's
no point using Automation -- its interpretive nature is meant to help
when either end is NOT under your control:-).

> with VARIANTs directly.

...which is still (a modest amount of) marshaling compared to the
down-to-the-bare-metal you can do with custom COM interfaces.

> The cost in Automation is more that a well behaved
> server is supposed to coerce arguments into the form it requires
(int->real,
> string->number and even dereferencing byref arguments are often done) and
> this often requires a bunch of tests and translation code.

In the hypothetical "I write both the client and the server" scenario,
the cost of checking that the vt discriminant field of the VARIANT
discriminated union is exactly as I (the server) require it, is a
small part of the overall marshaling cost.  If one or more argument
VARIANT's are _not_ exactly as I require them, then my marshaling
costs rise, whether I specialcase the translations or delegate them
to the existing functions in the OLE infrastructure.

But it's still a cost of marshaling, as opposed to one of dispatching.
Most Automation clients cache dispatch-ID's, and so the Invoke call
reduces to one test of the usual idiomatic form (one-test index-in-
range checking):
    ((unsigned)dispid)<maxdispid
i.e. 2 machine instructions (unsigned-comparison, branch-if-above-equal
with the latter mostly-not-taken), then a lookup-and-branch using
dispid as the index in the (user-implemented) virtual table -- say
4/5 machine cycles in all versus the 2/3 machine cycles for a vtable
use that could dispense with the index-in-range checking (wide
per-architecture variation of course, but mostly in this ballpark).

The marshaling cost of checking all variant arguments is a loop of
N equality comparisons (for the vt fields) -- plus a lot if one or
more equality-checks fail, of course:-).  But even without any
translations, each argument access is quite a bit costlier than
going directly to the stack for it -- indeed, if your code does
a lot with its args, it may be worthwhile unmarshaling them to
stack beforehand:-).


Alex