Re: Performance problem of imap move

[david.goldberg6@verizon.net (Dave Goldberg)]

> It appears that the change associated with this thread has caused a problem
>  for me at work.  After doing a git pull and recompiling (as usual) I
>  noticed some strangeness with some of the groups on our office365 set up.
>   I use a group line format of
>
>  %S%p%P%(%G [(%y new,%T !,%I ?)/~%t]%)
>
> A number of groups, though not all, initially showed up with all the article counts showing as a '*'.  Running M-g on the group resulted in an error that I regret not recording.  I then ran M-c to clear data and M-g again and the article counts showed as ridiculously high and Emacs hung long enough when trying to enter the group that Gnome offered to kill it off for lack of response.  I ran git bisect and it determined that this
>
> 447c56af7cb2afac14a0f3ed23f85d907c443a5d is the first bad commit
> commit 447c56af7cb2afac14a0f3ed23f85d907c443a5d
> Author: Lars Ingebrigtsen <larsi@gnus.org>
> Date:   Mon Jan 26 13:50:20 2015 +1100
>
>     Make moving IMAP articles faster in large groups
>     
>     * lisp/gnus-group.el (gnus-group-get-new-news-this-group): Explicitly
>     request rescans when being run interactively.
>     
>     * lisp/gnus-int.el (gnus-request-group-scan): New backend function.
>     
>     * lisp/nnimap.el (nnimap-request-scan-group): Implement in on IMAP.
>     
>     * lisp/nnimap.el (nnimap-request-group): Don't rescan the group here,
>     because that can be very slow in large groups.
>
> :040000 040000 3164108231527becdb471bfe74ce22bdd3bc5b4f
> d424a0d925e35e71fc30863580e2ca949559505e M lisp
 [...]

The latest checkout seems to have resolved the problem.

Thanks,
-- 
Dave Goldberg
david.goldberg6@verizon.net