Re: Orbit Performance Questions

[<dahaverk rockwellcollins com>]

We've done some preformance testing with ORBit  (not ORBit2).  We'd planned
basicly to post the information to the Net.  We compared ORBit with MICO
and ACE TAO.   However it does involve a number of Charts and isn't exactly
appropriate to post to an e-mail list.  We just haven't had time to
organize the information into a suitable form to send out.

Suffice it to say....  ORBit 0.5.8-12 is slightly faster than ACE TAO on
most things.   ACE TAO does have slightly better handling of CORBA Any's
though and isn't a slouch.  Also, ORBit win's on the executable size
comparason.  MICO and ACE TAO are HUGE.   Thus, not very suitable for
embedded systems.

I would like to see an ORBit2 version that is sub-settable to meet the
"minimum-CORBA" specification.  (i.e. No Dynamic stuff)   Plus, for
embedded work I'd like to eliminate "Any" handling.  Although I don't think
that is called out in the OMG specifications.  Removal of "Any's" and the
associated Marshalling to handle them can reduce the footprint even
further.

I must admit, I haven't sat down and analyzed exactly what functionality is
in ORBit/ORBit2 and how closely they match specific OMG specifications.

Dave Haverkamp





Michael Meeks <michael@ximian.com>@gnome.org on 12/31/2001 04:36:51 AM

Please respond to orbit-list@gnome.org

Sent by:  orbit-list-admin@gnome.org


To:   anil kumar <anilk@cdotd.ernet.in>
cc:   orbit-list@gnome.org

Subject:  Re: Orbit Performance Questions


Hi Anil,

On Fri, 2001-12-28 at 13:54, anil kumar wrote:
>   I am new to ORBIT and CORBA,  right now i am looking at the
>   performance of ORBIT  so that i can use it for  Real Time
>   Software Development. We are also planning to  put
>   ORB code into Linux Kernel also if some performance issues
>   come(So we need Open Source ORB ).Some ORB i have found
>   from  Internet are ORBIT,MICO,TAO.

     Sure.

>        I have some  basic doubt how   communication takes
>   place when the client and server both are running on the same
>   machine.

     Well - that is moderately pluggable ;-) if you have some brilliant
plan
for how to do this, it should be easy to plug a new approach in - after
all in Kernel land you have more possibilities.

     Essentialy there are two approaches - if we are in-proccess we invoke
the C method via a direct function pointer cast from the vtable - if it
is non NULL doh - I'll just paste the stub. This is all for ORBit2 BTW.
ORBit1 uses a somewhat more bloated and to my mind inferior approach.


Bonobo_Canvas_ArtUTA *
Bonobo_Canvas_Component_update(Bonobo_Canvas_Component _obj,
                      const Bonobo_Canvas_State * state,
                      const Bonobo_Canvas_affine aff,
                      const Bonobo_Canvas_SVP * clip_path,
                      const CORBA_long flags, CORBA_double * x1,
                      CORBA_double * y1, CORBA_double * x2,
                      CORBA_double * y2, CORBA_Environment * ev)
{
   Bonobo_Canvas_ArtUTA *_ORBIT_retval;

#ifndef ORBIT_STUB_DEBUG_LOCAL
   if (ORBIT_STUB_IsBypass(_obj, Bonobo_Canvas_Component__classid)) {
      ORBIT_STUB_PreCall(_obj);
      _ORBIT_retval =
      ((POA_Bonobo_Canvas_Component__epv *)
       ORBIT_STUB_GetEpv(_obj,
                   Bonobo_Canvas_Component__classid))->
      update(ORBIT_STUB_GetServant(_obj), state, aff, clip_path, flags, x1,
          y1, x2, y2, ev);
      ORBIT_STUB_PostCall(_obj);
   } else
#endif    /* ORBIT_STUB_DEBUG_LOCAL */
   {                /* remote marshal */
      gpointer _args[] = {
      (gpointer) state, (gpointer) aff, (gpointer) clip_path,
         (gpointer) & flags, &x1, &y1, &x2, &y2
      };

      ORBit_small_invoke_stub(_obj,
                     &Bonobo_Canvas_Component__iinterface.methods.
                     _buffer[0], &_ORBIT_retval, _args, NULL, ev);

   }
   return _ORBIT_retval;
}

     So you see we can pass it straight off through the Entry Point Vector
(epv - a sort of vtable ) to the method - OR

     we push the args into a normalized form [ defined in
interface-indirection.gnumeric ] and call the generic
'ORBit_small_invoke_stub' method. If this is called in-proc then these
arguments [ in the standard form ] are passed to the pluggable 'Skel'
code for that object / interface. This is to allow trivial cross
language method invocation - you could plug a marshaler there for the
client side I think. Otherwise if it is out of proc the code genericaly
marshals the arguments to the Common Data Representation (CDR) AFAIR;
see orbit-small.c.

>  a:  Whether the  data is converted  to the XDR format or not?

     XDR - no idea, it is always converted to IIOP in the remote case, the
in-proc case is rather different.

>  b:  What IPC mechanism ORBIT uses for communication?

     Fast Unix Domain Sockets on the same machine, otherwise we can use
IPv6/IPv4 sockets / IRDA etc. + SSL ( in theory ) so ... a number of IPC
mechanisms.

>  c:  How Communication takes place when the Client  and Server
>      both are running on different machine?

     as above really.

>  d:  Is Corba suited for Real Time Application or not?

     Possibly - with the new non-blocking code going into ORBit2 it might
become more suitable; it depends how hard your realtime requirements are
I suppose.

>      I am also interested in orbit source code so that
>   if  some performance bottleneck is found then  optimisation
>   of code can be done. So , please let me know from which point i
>   should start  reading code.

     You should checkout the 'linc' and 'ORBit2' modules from Gnome CVS [
see http://developer.gnome.org for details ]. Most of the ORB can be
understood by a little reading of:

     orbit-small.c, corba-any.c, poa.c, corba-object.c all in
ORBit2/src/orb/orb-core & src/orb/poa.

>     If anyone of  you have some ORBs performance document then
>     please  send me the URL.

     Sadly not - we do however have a set of known optimizations that we
should make sometime - with the bincompat overhead to make them as
ORBit2 stabilizes.

     HTH,

          Michael.

--
 mmeeks@gnu.org  <><, Pseudo Engineer, itinerant idiot

_______________________________________________
orbit-list mailing list
orbit-list@gnome.org
http://mail.gnome.org/mailman/listinfo/orbit-list