nmh-workers
[Top] [All Lists]

Re: [Nmh-workers] IMAP testing, again

2017-11-09 16:14:42
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

-- 
Nmh-workers
https://lists.nongnu.org/mailman/listinfo/nmh-workers

<Prev in Thread] Current Thread [Next in Thread>