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