>> BTW, it turns out it takes on average 0.66 seconds to append a message >> to a Gmail mailbox > >So refiling the half a dozen emails that are a thread I've just finished >with would be about six seconds because that's appending? (I don't know >IMAP.)
Well, "it depends". APPEND means "add a new message to the mailbox", and after you send that command you send the message. If you want to do a refile BETWEEN IMAP mailboxes, then you could use MOVE IF your IMAP server supports that (Gmail does), or you could use COPY and then delete the old message. So a hypothetical refile beween a MH store and a IMAP server would require the use of APPEND, but between two IMAP mailboxes it wouldn't. When I did some tests with COPY, it was fast. It looks like the delay is bringing into Gimap; once it's in things go pretty quickly. >> (tls-encrypted) => A2 SELECT "Enron" > >........................................................................ > >> (tls-decrypted) <= * 480832 EXISTS > >........................................................................ > >> Command (SELECT) execution time: 4.457428 sec >> >> I don't even have an idea how long it would have taken for nmh to do a >> readdir() on a directory with that many files. > >On my normal slow machine on ext4, reading the current directory of `.', >`..', and files {1..480832} takes > > $ time ls -f >/dev/null > > real 0m1.184s user 0m0.599s sys 0m0.585s $ Hm, the best I can get here is: /usr/bin/time ls -f > /dev/null 9.11 real 0.47 user 0.75 sys I'm not sure if that's because this MacOS X machine is older, has an older OS, or it just doesn't cache dirents as much. >> Strangely, the speed of adding messages to that mailbox seemed to not >> depend on the number of messages in the mailbox > >You're thinking it would be O(n log n) or similar so you'd see an >effect? Yeah, I was thinking there would be some per-folder metadata to slow it down. >Google is indexing the emails and the search is consulting that index. >We could do the same, or the user could use one of the existing email >indexers on their ~/mail, or we could integrate one of those if it's >installed. Sure, we COULD do that, or let Google do it for us :-) Anyway, I felt the data was interesting. It sort of suggests that on some IMAP servers there is a fall-off point where the mailbox gets rather large and painful to deal with. A caching daemon that had one connection per mailbox would be a win in those cases. --Ken -- Nmh-workers https://lists.nongnu.org/mailman/listinfo/nmh-workers