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

Previous Next

Full log

View this message in rfc822 format

From: Andrew Cohen <cohen <at> bu.edu>
To: Manuel Giraud <manuel <at> ledu-giraud.fr>
Cc: 63842 <at> debbugs.gnu.org, cohen <at> andy.bu.edu
Subject: bug#63842: 30.0.50; Slow 'gnus-summary-refer-thread'
Date: Sat, 03 Jun 2023 07:32:26 +0800

Dear Manuel:

>>>>> "MG" == Manuel Giraud <manuel <at> ledu-giraud.fr> writes:

    MG> Hi, Since sometimes now, in Gnus summary, calling 'A T'
    MG> (gnus-summary-refer-thread) is really slow (30 seconds to 1
    MG> minute) and it was instantaneous before.

Thanks for the bug report, and thanks for finding what is causing the
slowdown. The variable 'gnus-read-all-available-headers causes gnus to
parse all the headers it has available. There are some cases in which
this is needed to adequately find the referring thread, but others where
it is unnecessary. We can almost certainly move this to restrict to
those cases where it is really necessary and hopefully fix the
problem. We just need to know a bit more about which cases are slow (for
example, for me with mostly imap groups, there is no slowness).

Can you tell me (for circumstances where the referral is slow):

1. What kind of group and the backend used  in the group from which you
did the referral (imap, nntp, etc)
2. What search engine are you using (imap, notmuch, etc)
3. When the thread referral happens which groups are getting searched?
(In particular, what is the value of
'gnus-refer-thread-use-search? And is the search on the full server or
is it restricted to a single group?). And can you tell if the same set of
groups is being searched before and after the slowdown appeared?

Thanks for helping finding and fixing this.

Best,
Andy




-- 
Andrew Cohen

Previous Next

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