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

Previous Next

Full log

View this message in rfc822 format

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: bug#63842: 30.0.50; Slow 'gnus-summary-refer-thread'
Date: Mon, 19 Jun 2023 17:44:37 +0200

Andrew Cohen <cohen <at> bu.edu> writes:

>>>>>> "MG" == Manuel Giraud <manuel <at> ledu-giraud.fr> writes:
>
>     MG> Andrew Cohen <cohen <at> bu.edu> writes:
>     >> OK, I think I understand the problem.
>
> [...]
>
>     MG> From my tiny testing set, it does not seems to me that parsing
>     MG> all the headers is the way to go: the call to
>     MG> 'gnus-search-run-query' in gnus-search.el line 2206 directly
>     MG> returns direcly the correct set of messages and the call to
>     MG> 'gnus-get-newsgroup-headers-xover' later looks like some "deep"
>     MG> search (eg. on subject content).
>
> OK, I understand it now.  This isn't really about searching, or subject
> content (the fact that Manuel sees some articles not in the thread but
> with similar subject remains a bit of a mystery).

It is a mistery to me too.  If 'gnus-get-newsgroup-headers-xover' job is
to gather messages from the same thread, I think there is something
wrong here.  I'm still searching.

> To get everything right, any articles in the thread that need to be
> added to the summary buffer have to be added to the dependencies
> hash. In the case of searching we know exactly which articles need to
> be added so we have no need for 'gnus-read-all-available-headers to be
> non-nil: the "found" articles are each added to the hash. The only
> case where 'gnus-read-all-available-headers needs to be non-nil is
> when we don't know exactly which articles are part of the thread in
> which case we have to parse a larger set. This is what happens in the
> 3rd case in the conditional (the "t" clause) in
> 'gnus-summary-refer-thread. That is, this variable is only relevant in
> those cases where we don't have a configured search engine and just
> retrieve a lot of headers and hope for the best. So the setting of
> 'gnus-read-all-available-headers is just in the wrong place.

Thanks.  I don't know for other backends/search engines but a binding of
'gnus-read-all-available-headers' to t elsewhere will sure fix my issue.
-- 
Manuel Giraud

Previous Next

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