bug#36714: 27.0.50; Gnus nnmaildir taking long time to recursively visit sub-Maildirs

[Eric Abrahamsen <eric@ericabrahamsen.net>]

Eric Abrahamsen <eric@ericabrahamsen.net> writes:

> Jean Louis <bugs@gnu.support> writes:
>
>> * Eric Abrahamsen <eric@ericabrahamsen.net> [2019-07-22 19:40]:
>
> [...]
>
>>> I also don't think this threatens the integrity of the user's files: the
>>> extra data is maintained in parallel, and doesn't interfere with the
>>> messages themselves.
>>
>> I did read nnmaildir info page, and I have not found anything that
>> would indicate what would Gnus do to my file system.
>
> The first paragraph of the maildir section of the Gnus manual says:
>
> ‘nnmaildir’ also stores extra information in the ‘.nnmaildir/’ directory
> within a maildir.
>
> On the next page of the manual, there's a section on this group parameter:
>
> ‘nov-cache-size’
>      An integer specifying the size of the NOV memory cache.  To speed
>      things up, ‘nnmaildir’ keeps NOV data in memory for a limited
>      number of articles in each group.  (This is probably not
>      worthwhile, and will probably be removed in the future.)  This
>      parameter’s value is noticed only the first time a group is seen
>      after the server is opened—i.e., when you first start Gnus,
>      typically.  The NOV cache is never resized until the server is
>      closed and reopened.  The default is an estimate of the number of
>      articles that would be displayed in the summary buffer: a count of
>      articles that are either marked with ‘tick’ or not marked with
>      ‘read’, plus a little extra.
>
> Noting both that the nov cache will probably go away at some point, and
> how to control its size in the meantime.
>
> (add-to-list 'gnus-parameters
> 	     '("^nnmaildir:"
> 	       (nov-cache-size . 2)
> 	       (expire-age . never)))

Actually, `expire-age' isn't really necessary: so long as you don't mark
any articles with the "E" key, nothing will get expired.