Re: [Nmh-workers] IMAP testing, again

[Ralph Corderoy]

Hi Valdis,

> >     real    0m1.184s
> >     user    0m0.599s
> >     sys     0m0.585s
> >
> > Both have had the command previously run recently, but then
> > manipulation of an nmh folder tends to keep the interesting data in
> > memory.
>
> Yeah, the pain is in the cache-cold state. Especially if you're still
> in the spinning-rust world.

As I am.  I didn't know if Gmail hadn't been tickled for that example
IMAP mailbox recently, but assumed not for the comparison.

There are clearly two distinctive non-IMAP use cases...

Fumbling around with the same folder or two at length during everyday
mail handling;  then at least the dirents will be cached so finding out
the filenames for the folder's messages, e.g. 1-31415 with gaps, doesn't
wait for rust so it doesn't delay last:42 or inc-ing to 31416.  And
scanning last:42 is also avoiding rust because the tail end of the
messages are the ones already read into RAM, or just written from RAM by
inc, but still available.

The second case is suddenly wanting to dig around that archive folder,
i.e. one not accessed for an hour or two and so the dirents aren't
cached, nor the messages' content.  If the number of messages to read is
limited, e.g. not a pick though all, but a scan of the first:N or
last:N, or just finding out the highest message number to use N+1 for
the refile destination, then it's not too bad.  But in the case of
reading at least the start of every message from rust, nmh doesn't help
by reading 1, 2, 3... instead of in disk-address order.

If I know I'm going to pick the whole folder then I sometimes pre-fill
the OS cache more quickly by doing just that.  nmh could instead;  at
least on OS that supported it.

Also, a cache of the message numbers in a folder, e.g. filenames
suitable as message numbers, could presumably be maintained per folder,
and the folder's directory's modification time used to invalidate the
whole cache as that's updated on changes to the list of entries in the
directory?  This would vitally still allow manipulation of the folder
outside of nmh, e.g. `rm mail/inbox/42', without needing extra
cache-invalidation commands to mop up.  Checking if the cache is valid
and reading it would be near 0 s.

-- 
Cheers, Ralph.
https://plus.google.com/+RalphCorderoy