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 -- ## List details at http://www.exim.org/mailman/listinfo/exim-dev Exim details at http://www.exim.org/ ##
