pcg@aber-cs.UUCP (Piercarlo Grandi) (03/15/89)
In Elm 1.7 there is a table of all headers in the mailbox, called
"header_table", that is realloc'ed to increase its size whenever
the number of headers increases.
It would help a lot, and impact performance minimally, or actually
probably increse it, to allocate a table of POINTERS to
headers, even with a pretty large initial size, and then allocate the
headers one by one within it.
This would have TWO large advantages for poor 286 like machines:
* It does not require all the headers to be contiguous, therefore
it becomes possible to allocate more than a segment worth of headers
for mailboxes with many messages.
* It avoid realloc'ing a potentially large table, that most probably
requires a new larger one to be allocated, the old one to copied
into it, and the old one freed, and most likely not used any more.
It also the obvious advantage of helping with sorting speed, because only
pointers would have to be arranged.
I am doing a quick'n dirty fix to 1.7 to implement this, and it is fairly
easy. Please do the same more elegantly to Elm 2.2... I would vote for
having a fixed size pointer table, with a configurable size, or to allocate
it once with malloc with either a default size or one read from the
environemtn or the command line. I do not think that realloc'ing such a
table would buy much.
--
Piercarlo "Peter" Grandi | ARPA: pcg%cs.aber.ac.uk@nss.cs.ucl.ac.uk
Dept of CS, UCW Aberystwyth | UUCP: ...!mcvax!ukc!aber-cs!pcg
Penglais, Aberystwyth SY23 3BZ, UK | INET: pcg@cs.aber.ac.uksyd@dsinc.UUCP (Syd Weinstein) (03/17/89)
In article <772@aber-cs.UUCP> pcg@cs.aber.ac.uk (Piercarlo Grandi) writes:
:In Elm 1.7 there is a table of all headers in the mailbox, called
:"header_table", that is realloc'ed to increase its size whenever
:the number of headers increases.
:
:It would help a lot, and impact performance minimally, or actually
:probably increse it, to allocate a table of POINTERS to
:headers, even with a pretty large initial size, and then allocate the
:headers one by one within it.
Our own use of 286 type systems within the group has already forced
a similar change.
PS, its too late to ask for changes to be in 2.2, the freeze date
for 'changes' was 3/1/89. All change requests are now for 2.3.
2.2 is in the final stages of bug shakeout.
--
=====================================================================
Sydney S. Weinstein, CDP, CCP Elm Coordinator
Datacomp Systems, Inc. Voice: (215) 947-9900
{allegra,bpa,vu-vlsi}!dsinc!syd FAX: (215) 938-0235