Re: Some performance notes

[Tim Janik <timj gtk org>]

On 6 Aug 2001, Owen Taylor wrote:

> Johannes Stezenbach <js convergence de> writes:
> 
> > Owen Taylor wrote:
> > > 
> > > So, without including hard data (I don't have much), here are
> > > my observations:
> > 
> > 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.
> > 
> > Enabling mem chunks did not help, and my guess was
> > that a lot of GValue default property value copying
> > is going on during g_object_new().

that should only happen if you use CONSTRUCT arguments.

> > (Which IMHO is unnecessary since each class has an init
> > function to take care of this more efficiently.)
> > 
> > After I removed the g_object_class_install_property() stuff,
> > object creation was faster, but is still way to slow compared
> > to just malloc'ing plain C structs for holding the data.

assuming you don't use CONSTRUCT properties, i find this mildly
odd, can you provide two stand-alone test cases, one with the
g_object_class_install_property() stuff and one without?

> I can see places in the g_object_new()/g_type_create_instance()
> code paths which look like they could be optimized, but
> in the absence of real benchmarking information, that's
> fairly theoretical.

even if theoretical, i'd be interested in hearing what you'd want
to speed-up there, especially for g_type_create_instance().

> A pretty noticeable improvement for the non-threaded case 
> would be to reduce locking overhead when we aren't 
> initialized for threads. 
> 
> #define G_READ_LOCK(rw_lock)    g_static_rw_lock_reader_lock (rw_lock)
> 
> in gobject.c is always a function call, but if you trace
> down the G_LOCK() macro used elsewhere, you'll see it doesn't
> make a function call unless threading is enabled.

do you have any indication of g_static_rw_lock_reader_lock() actually
consuming significant time for the non-threaded case?

> For the threaded case, some attention to locking and unlocking
> less would be good - for instance, look up a type node and
> keep the result, instead of keeping locking and looking it
> up. 

i'm not sure what you are imagining here, usually the type system
acquires and releases a read-lock per function call in order
to be able to lookup type nodes, unless callbacks are being called,
in which case locks have to be released.
obviously, type nodes can't be cached across different API entries
of the type system, so i'm not quite getting what you're aiming at.

> 
> Regards,
>                                         Owen
> 

---
ciaoTJ