Re: Some performance notes

[Johannes Stezenbach <js convergence de>]

Owen Taylor wrote:
> 
> Johannes Stezenbach <js convergence de> writes:
> 
> > I use the GLib type system for non-GUI stuff, and I
> > recently found out that object creation is quite slow,
> > i.e. creating thousands of objects takes seconds. Many
> > seconds on an embedded platform having a 100 MHz ARM.
...
> > Do you have any ideas how to speed that up?
> 
> Well, the steps to fixing any performance problem are:
> 
>  - write a benchmark
> ...


OK, I don't want to dig too deep into the internals of the
GLib type system right now, but I did a few more tests
(on a PIII/733 MHz):

  int i;
  GObject *obj[10000];
  for (i = 0; i < 10000; i++)
    obj[i] = g_object_new (G_TYPE_OBJECT, NULL);

takes about 20 msecs. Not too bad ;-)

The same using

    obj[i] = g_cim_list_new ();

takes 700 msecs, having the following class hierarchy:

  GObject
    GCimObject
      GCimSerializable
        GCimContainer
          GCimList

GCimObject has two properties, GCimSerializable none, GCimContainer
one and GCimList one (one string, one int and two enums).
Commenting out all the g_object_class_install_property()
calls and the corresponding arguments to g_object_new() in g_cim_list_new()
makes the

    obj[i] = g_cim_list_new ();

run in 45 msecs.

(In my previous test I removed the properties just from one class (a different
one as in this example, one that had many properties), not from all
classes in the class hierarchy. Thus the speed-up was not as dramatical,
just a factor of three.)


Superficially glancing over the code in gobject.c I can see
two possible reasons for the g_object_new() slowness:
- properties are identified by strings, where g_param_spec_pool_lookup()
  has to parse the class_name:property_name combination (twice, once in
  g_object_new_valist, and again in g_object_newv)
- lots of copying of default values and init'ing with GParamSpecs,
  GParameters and GValues while creating a GParameter array from the
  va_list, splitting that into constructor args and normal args,
  calling the object's constructor, setting non-constructor args
  and emitting notify signals for them

My (hopefully wrong) conclusion: The GLib property system may be fine
for script language bindings or libglade kind of stuff, but if you
want performance, don't use it.

I hope you vehemently disagree, and enlighten me why it is
implemented the way it is.


Regards,
Johannes