[omniORB] Flick CORBA IDL compiler

[Brent Fulgham]

> From our measurements, the time to marshal data arguments is
> only a minor contributor to the overhead. The bulk of the time is spent
> somewhere else.  Usually, the time spend in the kernel contributes to half
of
> the null echo time. If we get rid of the protocol stack in the kernel,
like
> we have done when running omniORB2 over SCI between two pentium pro
> linux, we are getting 152 micro second null echo. I estimates that around
a
> 100 is used in the runtime, the rest is the latency of the hardware. At
this
> performance level, any saving in data marshalling time becomes
> significant. With good old TCP/IP, the gain in data marhsalling may not be
> noticeably.
>
> Sai-Lai
>

Has anyone tried to optimize omniidl2's code generation to make it a bit
more efficient when generating the stubs/skeleton implementation of the
IDL?  I'm working on a project consisting of approximately 50 or 60
separate IDL "methods".  We are seeing ~50K of IDL code expanding
to over 1 Meg of *SK.cc code.

For every interface that gets "compiled" by omniidl2, we get a new
proxy class, helper class, skeleton class, superclass, proxy factory
class, lifecycle skeleton class, lifecycle wrapper, lifecycle proxy,
any-packing operator, marshall, unmarshall, and dispatch code.   A lot of
implementation code which differs only by a small type parameter in
isn't being factored or virtualized, it just gets duplicated for each
interface.

I don't know what the efficiency of Flick is in terms of producing "small"
code, but it might have a few ideas about how to reduce the expansion we are
seeing in omniidl2.

Any comments greatly appreciated.

-Brent