--On Tuesday, September 16, 2003 09:52:53 +0100 Philip Hazel
<ph10@???> wrote:
> On Mon, 15 Sep 2003, Pat Lashley wrote:
>
>> 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.
>
> For maximum speed you'd want to read the file into memory and that's
> all. To do that, you need to arrange for all the variables to map onto a
> fixed memory image. This is not what currently happens. The variables
> that are set by config are intermixed with other global variables.
Right. But I wasn't really going for maximum speed. My assumption
was that macro processing, include processing, and basic lexical
analysis and parsing were a sufficiently high percentage of config
file parsing to be worth optimizing down to reading a single pre-tokenized,
pre-parsed file. (With the hidden assumption that the config file is
read often enough to make any optimization worth while at all. And
the assumption that as long as the files don't change, the result of
parsing the config file doesn't change due to some other influence.)
>> 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.
>
> I keep forgetting that some file systems have really small block sizes
> these days. But yes, I guess if people keep all the comments in the
> default config, it is bigger than I was suggesting.
No, that is disk blocks; which have been 512 bytes for a couple of
decades now. Modern filesystems do tend to work in some multiple
of disk blocks for the base level I/O; but that multiple is often
a tunable. And even when it isn't, it varies widely among different
OSes and filesystem types.
>> (But, like I said, it's a bikeshed...)
>
> Why don't you patch your Exim to measure the time it takes to read your
> config (cpu, real), and see if it is at all significant???
Tempting. But that would imply that I would actually have the cycles
free to do something useful with that informatin once I had it...
And I wouldn't have to search my ideas list very hard to find better
Exim-related projects to consume any free cycles I can come up with.
(Like full libsasl2 support as a build-time option. Or 'headers
remove' support in the data ACL. Or maybe the addition of 'headers
replace' everywhere that 'headers remove' and 'headers add' are
available now.)
Actually, I just thought of that last one; and I suspect it would
be the easiest to do. The basic idea is a combination of the add
and remove functions. It would expand the string, then remove any
old instance(s) of the given header, then add a new one using the
expanded string. This would provide a clean way to do things like:
headers_replace Subject: [mumble] $h_subject
(Or similarly with a space instead of the underscore in a filter.)
-Pat
