bug#63842: 30.0.50; Slow 'gnus-summary-refer-thread'

[Manuel Giraud via "Bug reports for GNU Emacs, the Swiss army knife of text editors" <bug-gnu-emacs@gnu.org>]

Andrew Cohen <cohen@bu.edu> writes:

> OK, I think I understand the problem.
>
> Before the change that Manuel identified as the culprit of the slowdown,
>  thread referral resulted in the creation of a new ephemeral group to
>  hold the search results. One of the major features of the changes was
>  to try to add the articles from the search to the existing summary
>  buffer rather than create a new one (this is an important improvement
>  for a variety of reasons; for example, changes made in the additional
>  ephemeral buffer would be overriden when exiting the originating
>  buffer).
>
> So what Manuel is seeing: previously the new ephemeral group parses only
> the headers for the articles in the thread, while in the current
> implementation where the newly found articles are simply added to the
> existing summary buffer, all the headers in the original buffer are
> parsed.
>
> I need to figure out the right way to fix this. I think parsing the full
> set of headers is the right thing, but since it is slow that creates a
> problem. In the meantime, Manuel can you try setting
> 'gnus-refer-thread-use-search to t and see if this resolves your
> problem? (This should effectively restore the old behavior of creating a
> new ephemeral group to hold the search result).

So I have tested with 'gnus-refer-thread-use-search' set to t and it
works (and is fast) as it was before.  But, as you said, this creates a
new nnselect group.

From my tiny testing set, it does not seems to me that parsing all the
headers is the way to go: the call to 'gnus-search-run-query' in
gnus-search.el line 2206 directly returns direcly the correct set of
messages and the call to 'gnus-get-newsgroup-headers-xover' later looks
like some "deep" search (eg. on subject content).

Best regards,
-- 
Manuel Giraud