From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Andrew Cohen Newsgroups: gmane.emacs.bugs Subject: bug#63842: 30.0.50; Slow 'gnus-summary-refer-thread' Date: Sat, 17 Jun 2023 07:37:28 +0800 Message-ID: <87fs6rashz.fsf@ust.hk> References: <871qiu6m1f.fsf@ledu-giraud.fr> <87bkhxl9th.fsf@ust.hk> <87ilc44r3u.fsf@ledu-giraud.fr> <831qiduv5f.fsf@gnu.org> <87352rr8vz.fsf@ledu-giraud.fr> Mime-Version: 1.0 Content-Type: text/plain Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="32647"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Cc: cohen@bu.edu, Eli Zaretskii , 63842@debbugs.gnu.org, cohen@andy.bu.edu To: Manuel Giraud Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Sat Jun 17 01:38:24 2023 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1qAJ1M-0008I4-Ao for geb-bug-gnu-emacs@m.gmane-mx.org; Sat, 17 Jun 2023 01:38:24 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1qAJ12-0001cH-8F; Fri, 16 Jun 2023 19:38:04 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1qAJ10-0001c8-Ka for bug-gnu-emacs@gnu.org; Fri, 16 Jun 2023 19:38:02 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1qAJ10-0006YF-C3 for bug-gnu-emacs@gnu.org; Fri, 16 Jun 2023 19:38:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1qAJ10-00006U-3J for bug-gnu-emacs@gnu.org; Fri, 16 Jun 2023 19:38:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Andrew Cohen Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Fri, 16 Jun 2023 23:38:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 63842 X-GNU-PR-Package: emacs Original-Received: via spool by 63842-submit@debbugs.gnu.org id=B63842.1686958667377 (code B ref 63842); Fri, 16 Jun 2023 23:38:02 +0000 Original-Received: (at 63842) by debbugs.gnu.org; 16 Jun 2023 23:37:47 +0000 Original-Received: from localhost ([127.0.0.1]:50529 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qAJ0l-000061-BE for submit@debbugs.gnu.org; Fri, 16 Jun 2023 19:37:47 -0400 Original-Received: from andy.bu.edu ([128.197.41.152]:36080) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qAJ0j-00005o-EB for 63842@debbugs.gnu.org; Fri, 16 Jun 2023 19:37:45 -0400 Original-Received: from [193.176.211.165] (helo=clove) by andy.bu.edu with esmtpsa (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1qAJ0b-0003bj-Qs; Fri, 16 Jun 2023 19:37:39 -0400 In-Reply-To: <87352rr8vz.fsf@ledu-giraud.fr> (Manuel Giraud's message of "Fri, 16 Jun 2023 12:36:48 +0200") X-Spam_score: -2.9 X-Spam_score_int: -28 X-Spam_bar: -- X-Spam_report: Spam detection software, running on the system "andy.bu.edu", has NOT identified this incoming email as spam. The original message has been attached to this so you can view it or label similar future email. If you have any questions, see @@CONTACT_ADDRESS@@ for details. Content preview: Sorry, I have gotten busy with other things at the moment. >>>>> "MG" == Manuel Giraud writes: MG> Hi, So here is the crux of this issue. When using MG> 'gnus-summary-refer-thread' in a nnml group, Emacs ends up MG> calling 'gnus-get-newsgroup-headers-xover' (via MG> 'gnus-fetch-headers'). AFA [...] Content analysis details: (-2.9 points, 5.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP -1.9 BAYE X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Original-Sender: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.emacs.bugs:263490 Archived-At: Sorry, I have gotten busy with other things at the moment. >>>>> "MG" == Manuel Giraud writes: MG> Hi, So here is the crux of this issue. When using MG> 'gnus-summary-refer-thread' in a nnml group, Emacs ends up MG> calling 'gnus-get-newsgroup-headers-xover' (via MG> 'gnus-fetch-headers'). AFAIU in this function when MG> 'gnus-read-all-available-headers' is t, Emacs will parse *all* MG> of the " *nntp*" buffer content. In my case, this buffer is MG> quite big (about 50k lines and 23MiB) hence the slowness. Thanks for continuing to debug this. I am confused---why is the nntp buffer so full? The search routine should populate the buffer only with the headers of the articles found in the search (I am assuming that this list of found articles is not 50K lines long). Maybe the search is not working properly? Can you step through gnus-summary-refer-thread and in the conditional that retrieves the new headers can you tell me which branch of the conditional is chosen (there are three possibilities: 'gnus-request-thread, 'gnus-search-thread, and the clause with the comment "Otherwise just retrieve some headers"). MG>BTW, I also have examples where 'gnus-summary-refer-thread' gives me MG>some false positives (eg., not the same thread but part of the subject MG>matching) This is probably by design: in the olden days many mailers were broken and didn't handle the references header properly (I don't know if this is still the case). So by default gnus tries to use information from the subject header to help gather loose threads, which can result in articles not actually part of the thread being included. You can check if this is the reason for what you are seeing by setting (setq gnus-summary-thread-gathering-function 'gnus-gather-threads-by-references) and seeing if this makes a difference. Best, Andy -- Andrew Cohen