On Mon, 15 Sep 2003, Pat Lashley wrote:
> Hmm. A preprocessor that just did macro definition/expansion, .include
> processing and comment removal might be useful it the overhead of loading
> the included files looked like it was becoming significant. And it would
> be easy to do as a stand-alone contributed app.
>
> But I suspect that a bigger performance advantage could be had with
> an app that would compile the config file, complete with includes
> and macro expansions, into some byte-coded form; along with mods
> to exim's config file reader to enable it to read the pre-digested
> config.
I suspect that neither would produce an improvement that actually made a
worthwile difference. Certainly the second would either require complete
re-design of the way Exim holds the data, or code to interpret byte-code
that would be very similar to interpreting text.
Most Exim configs probably fit in a disk block or two. On a busy system,
these blocks are likely to remain in main memory all the time. On a
modern CPU, it doesn't take many resources to interpret. And remember,
Exim is not CPU-bound. What runs out when you add more and more load is
disk bandwidth, usually long before your CPU is bothered.
--
Philip Hazel University of Cambridge Computing Service,
ph10@??? Cambridge, England. Phone: +44 1223 334714.
Get the Exim 4 book: http://www.uit.co.uk/exim-book
