GNU bug report logs - #63842
30.0.50; Slow 'gnus-summary-refer-thread'

Previous Next

Package: emacs;

Reported by: Manuel Giraud <manuel <at> ledu-giraud.fr>

Date: Fri, 2 Jun 2023 13:18:02 UTC

Severity: normal

Found in version 30.0.50

Done: Eli Zaretskii <eliz <at> gnu.org>

Bug is archived. No further changes may be made.

Full log


Message #35 received at 63842 <at> debbugs.gnu.org (full text, mbox):

From: Manuel Giraud <manuel <at> ledu-giraud.fr>
To: Andrew Cohen <cohen <at> bu.edu>
Cc: Eli Zaretskii <eliz <at> gnu.org>, 63842 <at> debbugs.gnu.org, cohen <at> andy.bu.edu
Subject: Re: bug#63842: 30.0.50; Slow 'gnus-summary-refer-thread'
Date: Sun, 18 Jun 2023 22:57:32 +0200
Andrew Cohen <cohen <at> 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




This bug report was last modified 1 year and 326 days ago.

Previous Next


GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.