Re: Creation of many components & time

[monkeyiq dingoblue net au]

Michael Meeks wrote:

Just as an up front. I realise that the wau the echo sample works is out of
proc.
I am working on converting this to shlib for my playing, but the heat is not
allowing
much time when I can think on the computer lately. I provide this as it may
be
of interest to some people on the list... benchmarks for out of proc bonobos.

>         When you do 'bonobo_object_activate' you do an
> oaf_activate_from_id which is garenteed to go out of process to the oafd [
> and then for a shlib component back to your processes ]
>
>         Instead you should probably do:
>
> GNOME_ObjectFactory factory = oaf_activat_from_iid ("OAFIID:OfFactory",0);
>
>         Then you can do:
>
> Bonobo_Unknown new_object = GNOME_ObjectFactory_create_object (
>         factory, "OAFIID:TheObjectId", a stringlist, 0);
>
>         And this will be extremely fast.

Hmm, I did some more benchmarking... I added a ping method that takes a long
and
returns a long, this is called for each object created.
In retrospect this is actually using out of proc stuff.... From what I can
see of the
actual echo sample, I decided to post to the list in case somebody is
interested in
my findings anyway.

"My old way",,,
Real,4.791,4.469,4.494
User,1.32,1.28,1.45
Sys,0.12,0.21,0.14
,,,
meeks_mlist_style,,,
Real,3.5,3.245,3.3
User,1.48,1.09,1.3
Sys,0.18,0.2,0.13

The above is csv from gnumeric. Basically going from my old method to one
based
on getting the factory first and then making them (the two calls you cite
above) goes
from 4.5 to 3.3 seconds to make the *first* 1000. Each time the client is run
from there
without restarting the server there is a gradual extra cost for each new 1000
created.

I will prolly actually read the oaf code to see how it is activating stuff so
that I can maybe
gain extra speed. Also I will prolly use the raw corba calls to make the
object my self
and see how long it takes ORBit to chern them out.

BTW I added this to the echo client. This is with the sample from 0.31 run
against
binaries from 0.33 because I can get my 0.33 cvs to compile (will update and
try again).

My new method is:
// Taken from the gnome-components-list reply from m meeks. All blame for
code to monkeyiq
void
benchmark_meeks_mlist_style( int number_to_make )
{
 BonoboObjectClient *server;
 Demo_Echo           echo_server;
 CORBA_Environment   ev;
 CORBA_exception_init (&ev);
{
 char               *obj_id =
"OAFIID:demo_echo:fe45dab2-ae27-45e9-943d-34a49eefca96";
 char*    factory_oaf_id =
"OAFIID:demo_echo_factory:a7080731-d06c-42d2-852e-179c538f6ee5";
 int i = 0;
 GNOME_ObjectFactory factory = oaf_activate_from_id ( (gchar *)factory_oaf_id
,0,NULL,&ev );
 Bonobo_Unknown new_object;
 GNOME_stringlist *strlist = GNOME_stringlist__alloc();
 Demo_Echo the_echo;
 CORBA_long cl =0;

 for( i = 0; i < number_to_make; i++ )
 {

  new_object = GNOME_ObjectFactory_create_object (
   factory, obj_id, strlist, 0 );

  if(!new_object) {
   printf("Can not make the new object \n");
  }

  // Nasty and fast //
  the_echo = (Demo_Echo)new_object;

  cl = Demo_Echo_ping (the_echo, cl, &ev);

/*  if(!(i%100)) {
   printf("i is at %d\n",i);
  }
*/
 }

 CORBA_free(strlist);
}
CORBA_exception_free (&ev);
}

>
>
> > >         So the overhead is ~0 after factory activation.
> >
> > Well, I would assume that it would be slower because of stubs, and
> surely the
>
>
>         ie. 3 compares and another stack frame ~= 0.

hmm, the delay I admit is small, but if I call a virtual function in C++
I make sure that it needs to be virtual if I call it 1000+ times in a row...
every little bit adds up quickly when you are iterating so many objects.
(esp if you plan to iterate them often aswell).

BTW 1000 calls using IPC
long ping (long)
took 0.6 seconds on this machine. It will be interesting to see how long it
takes with inproc.


>
>
> > CORBA_alloc() - free() stuff when passing args... not that any of this
> > CORBA stuff can be helped :-)
>
>         None of that should be needed really.

Hmm, I was being too much of a corba pureist, assuming that things may be
out of proc later... I guess not using them would save hassle, because the
objects would be soo slow out-of-proc. Still leaves the unfortunate mesh of
CORBA_char and STL string but thats a whole nother life of agony.