Re: [gmime-devel] GMime, now faster than ever.
- From: Jeffrey Stedfast <fejj novell com>
- To: GMime Devel List <gmime-devel-list gnome org>
- Subject: Re: [gmime-devel] GMime, now faster than ever.
- Date: Sat, 13 Sep 2008 08:33:30 -0400
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]