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

[Jeffrey Stedfast <fejj novell com>]

One of the things I've been working on in 2.3.x is minimizing repeated
processing of the same strings. Optimizing this is likely mostly a waste
of effort in the grand scheme of things, but GMime is mostly to the
point where all that is left is tweaking, and since I find that
fun/challenging, I do it anyway ;-)

However, one thing I noticed the other day after Alex suggested the
addition of those parser APIs to get the begin/end offsets of a message
header block, is that parser_fill() was likely being used prematurely in
a lot of cases.

So, this morning as I watched the sun rise, I figured I'd take a look
and see if it was indeed being called in cases it didn't need to be
(e.g. we had plenty of data buffered).

Sure enough, I was right. There were plenty of smallish reads being
done. Probably mostly from scan_headers() and scan_from_line(), but
possibly also the loop in scan_content(). Luckily, since scan_content()
is where most of the I/O happens (because that's where most of the
message data is, usually), there were still plenty of full-buffer reads
so GMime's parser still flew.

In an attempt to suck every bit of raw power out of GMime's parser that
I could, I fixed it by adding an 'atleast' argument to parser_fill() so
that it would no-op if we had more than 'atleast' bytes.

After my fix, parser_fill() will now nearly always request 4096 bytes
from the system if it makes it past the 'atleast' check.

Here are some timing results:

pre-optimization:

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

real	0m8.877s
user	0m7.744s
sys	0m1.016s
[fejj serenity tests]$ time ./test-mbox

real	0m8.907s
user	0m7.760s
sys	0m1.036s
[fejj serenity tests]$ time ./test-mbox

real	0m8.900s
user	0m7.872s
sys	0m0.920s



post-optimization:

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

real	0m8.598s
user	0m7.596s
sys	0m0.860s
[fejj serenity tests]$ time ./test-mbox

real	0m8.564s
user	0m7.536s
sys	0m0.884s
[fejj serenity tests]$ time ./test-mbox

real	0m8.563s
user	0m7.620s
sys	0m0.820s



Nothing huge, but still a respectable improvement ;-)

Jeff