On Mon, 25 Sep 2006, Nico Erfurth wrote:
> as exim is reading the spool-files pretty often I started to browse through
> the code of spool_in.c on the hunt for places to optimize it a bit. I've found
> the "option-reading" code to be rather "direct" in it's approach, so I've
> changed it to check the first letter via a switch/case statement and reordered
> the code a bit to fit the scheme. On my system this brings down the string
> compares in this section for a usual message from 80-100 to 12-15.
12-15 what? Microseconds? Does this significantly affect the amount of
processing needed to handle a message. I'm afraid I'm a bit skeptical
that is will be significant, but I am not always good at guessing these
things. (And remember that Exim is I/O limited; cpu usage isn't usually
an issue.)
Aside: what has happened, of course, is that the number of things stored
on the spool has increased a lot since I first wrote that code. If we
are going to optimize it, maybe a binary-chop search on an ordered list
would be faster still?
> While looking in there, I was wondering why some compares use Ustrncmp, and
> others Ustrcmp. Backward-compatibility issues? As I wasn't sure about the
> reasons I've added tolower to the switch-statement.
Eh? The difference between Ustrcmp and Ustrncmp has nothing to do with
upper/lower case! It should all be in lower case.
> P.S. As this is a rather sensitive part of the code, please check the patch
> before commiting it. I'll be away for the rest of the week, so I won't be able
> to fix my errors this time. :)
I suspect I won't get to it till next week, in fact.
Philip
--
Philip Hazel University of Cambridge Computing Service
Get the Exim 4 book: http://www.uit.co.uk/exim-book
