--On Monday, September 15, 2003 17:14:05 +0100 Philip Hazel
<ph10@???> wrote:
> On Mon, 15 Sep 2003, Pat Lashley wrote:
>
> 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.
Hey, let's not ruin a perfectly good bikeshed discussion by injecting
common sense. :-)
And it might not take that much of a redesign - I was really aiming at
just eliminating the lexical scanning and some of the parsing overhead
at the point where the cofig file is read.
But you are definately right about it not being worth serious consideration
until we know just how long config file reading is taking.
> Most Exim configs probably fit in a disk block or two.
According to du, the configure.default on my FreeBSD system takes 54
blocks. I suspect that's very close to the average size; with actual
installations tending to be only a block or two larger.
> On a busy system,
> these blocks are likely to remain in main memory all the time.
This is a good point. And if the system isn't busy, the config file
parsing time isn't likely to matter. (Assuming the system is busy
with mail and not other things. But if that becomes an issue, it's
time for a dedicated mail server.)
> 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.
I was thinking startup time rather than overall load reduction.
(But, like I said, it's a bikeshed...)
-Pat
