Re: Some performance notes

[Owen Taylor <otaylor redhat com>]

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().
> (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.
> 
> (Sorry, I have no real benchmarks yet, but one of my test
> programs parses a 64K text file and creates 2500 objects
> from it. Parsing alone takes 0.25 sec., creating the
> objects takes 25 sec. (!) on the 100 MHz ARM (just below
> 1 sec on a 800 MHz Athlon). I normally prepend the objects
> to a GList, commenting out the prepend does not speed it up.)
> 
> 
> Do you have any ideas how to speed that up?

Well, the steps to fixing any performance problem are:

 - write a benchmark
 - read the code
 - profile the benchmark 
 - profile a real application to see if your benchmark
   is typical.
 - read the code some more
 - try a fix, see if it improves the benchmark
 etc.

:-). No magic bullets.

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.

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.

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. 

Havoc posted a benchmark here for object creation and signals
sometime last year ... we should put that into the tree.

Regards,
                                        Owen