From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Manuel Giraud via "Bug reports for GNU Emacs, the Swiss army knife of text editors" Newsgroups: gmane.emacs.bugs Subject: bug#63842: 30.0.50; Slow 'gnus-summary-refer-thread' Date: Sun, 18 Jun 2023 00:16:26 +0200 Message-ID: <87352ppwed.fsf@ledu-giraud.fr> References: <871qiu6m1f.fsf@ledu-giraud.fr> <87bkhxl9th.fsf@ust.hk> <87ilc44r3u.fsf@ledu-giraud.fr> <831qiduv5f.fsf@gnu.org> <87352rr8vz.fsf@ledu-giraud.fr> <87fs6rashz.fsf@ust.hk> Reply-To: Manuel Giraud Mime-Version: 1.0 Content-Type: text/plain Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="25380"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Cc: Eli Zaretskii , 63842@debbugs.gnu.org, cohen@andy.bu.edu To: Andrew Cohen Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Sun Jun 18 00:17:17 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 1qAeEP-0006Mw-9C for geb-bug-gnu-emacs@m.gmane-mx.org; Sun, 18 Jun 2023 00:17:17 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1qAeEC-0002TF-9p; Sat, 17 Jun 2023 18:17: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 1qAeEA-0002T3-Io for bug-gnu-emacs@gnu.org; Sat, 17 Jun 2023 18:17: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 1qAeEA-0007kp-A2 for bug-gnu-emacs@gnu.org; Sat, 17 Jun 2023 18:17:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1qAeEA-00058z-5j for bug-gnu-emacs@gnu.org; Sat, 17 Jun 2023 18:17:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Manuel Giraud Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sat, 17 Jun 2023 22:17: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.168704019519733 (code B ref 63842); Sat, 17 Jun 2023 22:17:02 +0000 Original-Received: (at 63842) by debbugs.gnu.org; 17 Jun 2023 22:16:35 +0000 Original-Received: from localhost ([127.0.0.1]:52763 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qAeDj-00058B-6M for submit@debbugs.gnu.org; Sat, 17 Jun 2023 18:16:35 -0400 Original-Received: from ledu-giraud.fr ([51.159.28.247]:46033) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qAeDe-00057w-SL for 63842@debbugs.gnu.org; Sat, 17 Jun 2023 18:16:34 -0400 DKIM-Signature: v=1; a=ed25519-sha256; c=simple/simple; s=ed25519; bh=swGtjN5X 03TrzZHok3slYAepqxYnBezHaaIitzDLYoo=; h=date:references:in-reply-to: subject:cc:to:from; d=ledu-giraud.fr; b=Pha6VKGaaMCP4QYsZZZbQzZLJay56D 8FGMXV5oXaodY8/Fr8yDZT9FqP6aWwJDuDe0abwvn7xsU5H/EDibxcCA== DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; s=rsa; bh=swGtjN5X03TrzZHo k3slYAepqxYnBezHaaIitzDLYoo=; h=date:references:in-reply-to:subject: cc:to:from; d=ledu-giraud.fr; b=tZw0fLnIQoQDpHFM2oL/vYbTC+BQPYfDNT231E 64qDqfZoEywhEvAKZrvpDkr40n7k4/0VWsuki+g6B6pCp+e0I2Lm/SjSmbhWMh8DkaUlUM SfRCKurP1ky+K2pYtD/WFO5WaZwfUVnL5gnHd7/pRis1UnjEtUkSpWUY8QxzK5TJrKcbB1 toGXJR79v+kZ1ryK3C6VMrzTXeDexqTqkL1kT9tdGhrSUypIJ5U1kKGDE2uHpF1AsaXzK+ fmTc/wvr9Wj6+jY9bNhLzsaGhPJz4UJ0cTvRo7l3Ax2K8x20odNmQJU+MmaVqJ0uCrpfKU 2IUKvsFADUqJTrhAXAggJ7wg== Original-Received: from computer ( [10.1.1.1]) by ledu-giraud.fr (OpenSMTPD) with ESMTPSA id e2a5ce33 (TLSv1.3:TLS_AES_256_GCM_SHA384:256:NO); Sun, 18 Jun 2023 00:16:29 +0200 (CEST) In-Reply-To: <87fs6rashz.fsf@ust.hk> (Andrew Cohen's message of "Sat, 17 Jun 2023 07:37:28 +0800") 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:263581 Archived-At: Andrew Cohen writes: > Sorry, I have gotten busy with other things at the moment. Hi Andrew and you don't need to be sorry for this :-) >>>>>> "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? I think in a nnml group the nntp buffer is populated with the content of the ".overview" file. In this particular group, I have thousands of messages and I think that explains the size of this file. > 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? As we are talking about 'gnus-summary-refer-thread', I guess that it is expected that the nntp buffer is filled with this content. A regular query (with 'G G') is still fast, so I think my search engine is set up 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"). In my case, Emacs is using the 'gnus-search-thread' branch and ends up calling 'gnus-get-newsgroup-headers-xover' which is the function that parses all the nntp buffer content. > 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. Ok, thanks for the explanation and FWIW, my 'gnus-summary-thread-gathering-function' is already set to 'gnus-gather-threads-by-references. Best regards, -- Manuel Giraud