> Hi Paul.  The WIMM mail scanner program scans my entire message
> base for new personal mail in around 9 seconds.  Msgedsq takes
> around 20 seconds to scan my entire messagebase for new mail
> (when I hit the '*' key).  Why is this?

ac> Also, Squish 1.11 (32-bit OS/2 native) takes ~12 seconds to scan
ac> my message base for outbound mail (when there is no mail to
ac> send).

ac> Also, it takes timEd/2 1.01 ~8 seconds to scan my message base
ac> for new mail.

ac> Also, it takes GoldED (DOS real mode) 2.50 ~10 seconds to scan my
ac> entire message base for new mail.

ac> Also, ... well, you get the picture.  ;-)

I did a whole lot of profiling yesterday, the original problem
being I was wondering why it was taking so long for a single
screen to be displayed in AUST_AVTECH.  The reason for that
turned out to be 2 things:

1. A sequential search was being done to convert a UID into a MSGN.
2. The entire index was being reread in order to do each conversion.

I was able to do something about number 1, and it is now a binary
search, and I'll have to release a new MSGAPI38 with that change.
Actually I'll post the changed code here.

Number 2 I don't know what to do about, it would require a lot of
work to fix that so that it did something smarter.

I then went and found why "*" took so long.  My index files are
1.5 meg in size, and unfortunately HPFS won't allow me more than
2 meg of disk cache.  I found that I must be near the limit on
that, because cutting out both AUST_AVTECH and AUST_TRADING from
my squish file allowed me to do a rescan with no disk activity
except right at the end, ie only a couple of seconds rescan time.

The internals are like this:

1. Since it is reading all the index files one at a time, by the
time the last one is read into memory, the first one has been
removed from cache due to lack of space.

2. The lastread files are being opened for update, which is where
one of the "write's" is coming from.

3. The SQD files are being updated (just the front bit) I think
in order to register # of uses.

4. There was also the sequential search of the UidToMsgN, but I
extended my binary search to include the UID_NEXT and PREV, so
that fixed that problem up too.

So to get the performance I want, I either need to put my messagebase
onto FAT or run HPFS386 again (last time I tried reinstalling that
it wouldn't install).

Then again, it's probably not such an issue anyway.  I don't spend
half my life doing rescans.  BFN.  Paul.
@EOT:

---