Re: [gmime-devel] GMime, now faster than ever.



Unfortunately, as I discovered last night, due mostly to my
InternetAddress* design changes in 2.3.x to use GObject and signals,
overall performance since 2.2.22 has dropped :(

Here are the run-times for 2.2svn for the same set of input I was using
to test 2.3.x yesterday:

[fejj serenity tests]$ time ./test-mbox

real	0m6.694s
user	0m5.436s
sys	0m1.076s
[fejj serenity tests]$ time ./test-mbox

real	0m6.614s
user	0m5.420s
sys	0m1.092s
[fejj serenity tests]$ time ./test-mbox

real	0m6.547s
user	0m5.472s
sys	0m0.984s


This is somewhat depressing...

So this morning I started up sysprof and did my best to try and optimize
some of the heavier hitters.

Here are the latest 2.3.x svn results:

[fejj serenity tests]$ time ./test-mbox

real	0m7.721s
user	0m6.748s
sys	0m0.876s
[fejj serenity tests]$ time ./test-mbox

real	0m7.711s
user	0m6.708s
sys	0m0.892s
[fejj serenity tests]$ time ./test-mbox

real	0m7.708s
user	0m6.692s
sys	0m0.912s


Still a full second slower than 2.2 svn :(


Part of the improvement over yesterday's run-times for 2.3.x were
because I unset my G_SLICE=always-malloc debug environment, which helped
a little, but most of the rest of it is tricks to keep signal emission
to a minimum and elimination of hash table lookups/maintenance.

What I've discovered is that GMime is spending a huge amount of time in
g_object_new() (and children) and signal handler maintenance (such as
g_signal_handlers_disconnect_matched) called from the dtors.

I'll keep trying to think of other ways to improve performance...

Jeff




[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]