From unknown Sat Jun 21 03:11:49 2025 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Mailer: MIME-tools 5.509 (Entity 5.509) Content-Type: text/plain; charset=utf-8 From: bug#63842 <63842@debbugs.gnu.org> To: bug#63842 <63842@debbugs.gnu.org> Subject: Status: 30.0.50; Slow 'gnus-summary-refer-thread' Reply-To: bug#63842 <63842@debbugs.gnu.org> Date: Sat, 21 Jun 2025 10:11:49 +0000 retitle 63842 30.0.50; Slow 'gnus-summary-refer-thread' reassign 63842 emacs submitter 63842 Manuel Giraud severity 63842 normal thanks From debbugs-submit-bounces@debbugs.gnu.org Fri Jun 02 09:17:45 2023 Received: (at submit) by debbugs.gnu.org; 2 Jun 2023 13:17:45 +0000 Received: from localhost ([127.0.0.1]:39349 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1q54f2-0000ov-LR for submit@debbugs.gnu.org; Fri, 02 Jun 2023 09:17:45 -0400 Received: from lists.gnu.org ([209.51.188.17]:41682) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1q54ey-0000ok-To for submit@debbugs.gnu.org; Fri, 02 Jun 2023 09:17:43 -0400 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 1q54ey-0000iF-Kl for bug-gnu-emacs@gnu.org; Fri, 02 Jun 2023 09:17:40 -0400 Received: from ledu-giraud.fr ([51.159.28.247]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1q54ev-0007n8-79 for bug-gnu-emacs@gnu.org; Fri, 02 Jun 2023 09:17:40 -0400 DKIM-Signature: v=1; a=ed25519-sha256; c=simple/simple; s=ed25519; bh=ojOZsuXL o8/NXiaoKZWc65NLSx942IqYONB44920+LQ=; h=date:subject:cc:to:from; d=ledu-giraud.fr; b=VWaaKvSfSteAnmjw9JGiI/0lp5ZuNJ4U+glcXMdPHX8TuL51EY RVODIoIeiX+IShxaxj0HZ44JVOazNaIj2VDA== DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; s=rsa; bh=ojOZsuXLo8/NXiao KZWc65NLSx942IqYONB44920+LQ=; h=date:subject:cc:to:from; d=ledu-giraud.fr; b=cZyk0DBC2LFlwvuMenEJKddXD3MTnoqmiY1nT7zYxBKccsfbKC m+Dz0NRycUA8Izg2ifjRqpu7/P8CMnl9nyacg3IS9xD9YzI+RxmaonjsbaA9i0/gjnvy6n enqw51gXns7OFf3sdG55A+G4ieaTPc100bAc0ZwaK3w4FBdE88hDgV3G0sgxTDAMcEXNqy xh4pXNzoWZyVWOMFZWc8BLFk2YSHeCX+jxSU9GFQ/2nFggvfTN4EmcJT+qM+pAQ+97BbdF 4/8B7aIF0fFdYbd7KrR4jssGrX+bXq6SZiR70LGtgEWqpuds9RV1/s5sw+zs958AEk4RSo H26nGwLs7GKw== Received: from computer ( [10.1.1.1]) by ledu-giraud.fr (OpenSMTPD) with ESMTPSA id b5eb1a3b (TLSv1.3:TLS_AES_256_GCM_SHA384:256:NO); Fri, 2 Jun 2023 15:17:33 +0200 (CEST) From: Manuel Giraud To: bug-gnu-emacs@gnu.org Subject: 30.0.50; Slow 'gnus-summary-refer-thread' Date: Fri, 02 Jun 2023 15:17:32 +0200 Message-ID: <871qiu6m1f.fsf@ledu-giraud.fr> User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain Received-SPF: pass client-ip=51.159.28.247; envelope-from=manuel@ledu-giraud.fr; helo=ledu-giraud.fr X-Spam_score_int: -20 X-Spam_score: -2.1 X-Spam_bar: -- X-Spam_report: (-2.1 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01 autolearn=ham autolearn_force=no X-Spam_action: no action X-Spam-Score: -1.4 (-) X-Debbugs-Envelope-To: submit Cc: cohen@andy.bu.edu X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -2.4 (--) Hi, Since sometimes now, in Gnus summary, calling 'A T' (gnus-summary-refer-thread) is really slow (30 seconds to 1 minute) and it was instantaneous before. I have bisected it to the following patch: bf986c1faf53f3abd260f72cb36d9143afac353d is the first bad commit commit bf986c1faf53f3abd260f72cb36d9143afac353d Author: Andrew G Cohen Date: Tue Nov 22 15:39:01 2022 +0800 Improve gnus thread-referral Allow thread referral to use search whenever possible, displaying the results in the current summary buffer if possible and a new nnselect buffer if not. * lisp/gnus/nnimap.el (nnimap-request-thread): Obsolete function. * lisp/gnus/gnus-search.el (gnus-search-thread): Allow detailed specification of how/where to search. Add found articles to the current summary buffer if possible, or create a new ephemeral nnselect group if not. * lisp/gnus/gnus-sum.el (gnus-refer-thread-use-search): Allow a list of servers and groups to search. (gnus-summary-refer-thread): Find thread-related articles by using a backend-specific method, gnus-search, or retrieving nearby headers in the current group. * lisp/gnus/nnselect.el (nnselect-search-thread): Obsolete function. (nnselect-request-thread): Allow thread referral from nnselect groups. * doc/misc/gnus.texi (Finding the Parent): Document changes to thread referral. In GNU Emacs 30.0.50 (build 1, x86_64-unknown-openbsd7.3, cairo version 1.17.8) of 2023-06-02 built on computer Repository revision: bf986c1faf53f3abd260f72cb36d9143afac353d Repository branch: HEAD Windowing system distributor 'The X.Org Foundation', version 11.0.12101006 System Description: OpenBSD computer 7.3 GENERIC.MP#1125 amd64 Configured using: 'configure --prefix=/home/manuel/emacs --bindir=/home/manuel/bin --with-x-toolkit=no --without-sound --without-compress-install CPPFLAGS=-I/usr/local/include LDFLAGS=-L/usr/local/lib' Configured features: CAIRO DBUS FREETYPE GIF GLIB GMP GNUTLS GSETTINGS HARFBUZZ JPEG JSON LCMS2 LIBOTF LIBXML2 MODULES NOTIFY KQUEUE OLDXMENU PDUMPER PNG RSVG SQLITE3 THREADS TIFF TREE_SITTER WEBP X11 XDBE XIM XINPUT2 XPM ZLIB Important settings: value of $LC_ALL: en_US.UTF-8 locale-coding-system: utf-8-unix Major mode: Group Minor modes in effect: global-git-commit-mode: t magit-auto-revert-mode: t gnus-topic-mode: t display-time-mode: t display-battery-mode: t server-mode: t gnus-undo-mode: t shell-dirtrack-mode: t override-global-mode: t repeat-mode: t desktop-save-mode: t global-eldoc-mode: t show-paren-mode: t electric-indent-mode: t mouse-wheel-mode: t menu-bar-mode: t file-name-shadow-mode: t global-font-lock-mode: t font-lock-mode: t blink-cursor-mode: t buffer-read-only: t line-number-mode: t indent-tabs-mode: t transient-mark-mode: t auto-composition-mode: t auto-encryption-mode: t auto-compression-mode: t Load-path shadows: /home/manuel/.emacs.d/elpa/ef-themes-1.0.2/theme-loaddefs hides /home/manuel/emacs/share/emacs/30.0.50/lisp/theme-loaddefs Features: (shadow shortdoc help-fns radix-tree magit-extras emacsbug pulse face-remap magit-submodule magit-obsolete magit-blame magit-stash magit-reflog magit-bisect magit-push magit-pull magit-fetch magit-clone magit-remote magit-commit magit-sequence magit-notes magit-worktree magit-tag magit-merge magit-branch magit-reset magit-files magit-refs magit-status magit magit-repos magit-apply magit-wip magit-log which-func magit-diff smerge-mode diff git-commit log-edit add-log magit-core magit-autorevert magit-margin magit-transient magit-process with-editor magit-mode transient magit-git magit-section magit-utils dash nnmaildir gnus-search sort gnus-cite mail-extr textsec uni-scripts idna-mapping ucs-normalize uni-confusable textsec-check gnus-async gnus-bcklg qp gnus-ml gnus-topic mm-archive url-cache utf-7 imap rfc2104 nndoc nndraft nnmh network-stream nnfolder nnml gnus-agent gnus-srvr gnus-score score-mode nnvirtual nntp gnus-cache nnrss org-agenda mule-util org-indent org-element org-persist org-id org-refile avl-tree oc-basic ol-eww ol-rmail ol-mhe ol-irc ol-info ol-gnus nnselect ol-docview ol-bibtex bibtex ol-bbdb ol-w3m ol-doi org-link-doi org ob ob-tangle ob-ref ob-lob ob-table ob-exp org-macro org-src ob-comint org-pcomplete org-list org-footnote org-faces org-entities ob-emacs-lisp ob-core ob-eval org-cycle org-table ol org-fold org-fold-core org-keys oc org-loaddefs org-version org-compat org-macs css-mode sh-script smie treesit executable vc-cvs vc-rcs log-view pcvs-util pascal eww xdg url-queue mm-url vc-git bug-reference paredit imenu doc-view jka-compr image-mode exif gnus-dired view vc-hg diff-mode vc-dispatcher vc-svn warnings rng-xsd xsd-regexp rng-cmpct rng-nxml rng-valid rng-loc rng-uri rng-parse nxml-parse rng-match rng-dt rng-util rng-pttrn nxml-ns nxml-mode nxml-outln nxml-rap sgml-mode facemenu nxml-util nxml-enc xmltok time battery cus-load exwm-randr xcb-randr exwm-config ido exwm exwm-input xcb-keysyms xcb-xkb exwm-manage exwm-floating xcb-cursor xcb-render exwm-layout exwm-workspace exwm-core xcb-ewmh xcb-icccm xcb xcb-xproto xcb-types xcb-debug server modus-operandi-theme modus-themes zone speed-type url-http url-auth url-gw nsm compat ytdious mingus libmpdee reporter edebug debug backtrace detached-init detached autorevert filenotify transmission color calc-bin calc-ext calc calc-loaddefs rect calc-macs supercite regi ebdb-message ebdb-gnus gnus-msg gnus-art mm-uu mml2015 mm-view mml-smime smime gnutls dig gnus-sum shr pixel-fill kinsoku url-file svg dom gnus-group gnus-undo gnus-start gnus-dbus gnus-cloud nnimap nnmail mail-source utf7 nnoo gnus-spec gnus-int gnus-range message sendmail yank-media puny rfc822 mml mml-sec epa epg rfc6068 epg-config mm-decode mm-bodies mm-encode mail-parse rfc2231 rfc2047 rfc2045 ietf-drums gmm-utils mailheader gnus-win gnus nnheader gnus-util mail-utils range mm-util mail-prsvr wid-edit ebdb-mua ebdb-com crm ebdb-format ebdb mailabbrev eieio-opt speedbar ezimage dframe find-func eieio-base pcase timezone visual-basic-mode cl web-mode derived disp-table erlang-start smart-tabs-mode skeleton cc-mode cc-fonts cc-guess cc-menus cc-cmds cc-styles cc-align cc-engine cc-vars cc-defs slime-asdf grep slime-tramp tramp rx tramp-loaddefs trampver tramp-integration files-x tramp-compat shell pcomplete parse-time iso8601 time-date ls-lisp format-spec slime-fancy slime-indentation slime-cl-indent cl-indent slime-trace-dialog slime-fontifying-fu slime-package-fu slime-references slime-compiler-notes-tree advice slime-scratch slime-presentations bridge slime-macrostep macrostep slime-mdot-fu slime-enclosing-context slime-fuzzy slime-fancy-trace slime-fancy-inspector slime-c-p-c slime-editing-commands slime-autodoc slime-repl slime-parse slime apropos compile text-property-search etags fileloop generator xref project arc-mode archive-mode noutline outline icons pp comint ansi-osc ansi-color ring hyperspec thingatpt slime-autoloads edmacro kmacro use-package-bind-key bind-key appt diary-lib diary-loaddefs cal-menu calendar cal-loaddefs dired-x dired-aux dired dired-loaddefs notifications dbus xml cl-extra help-mode use-package-core repeat easy-mmode desktop frameset speed-type-autoloads osm-autoloads ebdb-autoloads magit-autoloads debbugs-autoloads git-commit-autoloads finder-inf rust-mode-autoloads magit-section-autoloads ef-themes-autoloads with-editor-autoloads compat-autoloads dash-autoloads ytdious-autoloads transmission-autoloads paredit-autoloads exwm-autoloads hyperbole-autoloads detached-autoloads info package browse-url url url-proxy url-privacy url-expand url-methods url-history url-cookie generate-lisp-file url-domsuf url-util mailcap url-handlers url-parse auth-source cl-seq eieio eieio-core cl-macs password-cache json subr-x map byte-opt gv bytecomp byte-compile url-vars cl-loaddefs cl-lib rmc iso-transl tooltip cconv eldoc paren electric uniquify ediff-hook vc-hooks lisp-float-type elisp-mode mwheel term/x-win x-win term/common-win x-dnd tool-bar dnd fontset image regexp-opt fringe tabulated-list replace newcomment text-mode lisp-mode prog-mode register page tab-bar menu-bar rfn-eshadow isearch easymenu timer select scroll-bar mouse jit-lock font-lock syntax font-core term/tty-colors frame minibuffer nadvice seq simple cl-generic indonesian philippine cham georgian utf-8-lang misc-lang vietnamese tibetan thai tai-viet lao korean japanese eucjp-ms cp51932 hebrew greek romanian slovak czech european ethiopic indian cyrillic chinese composite emoji-zwj charscript charprop case-table epa-hook jka-cmpr-hook help abbrev obarray oclosure cl-preloaded button loaddefs theme-loaddefs faces cus-face macroexp files window text-properties overlay sha1 md5 base64 format env code-pages mule custom widget keymap hashtable-print-readable backquote threads dbusbind kqueue lcms2 dynamic-setting system-font-setting font-render-setting cairo xinput2 x multi-tty make-network-process emacs) Memory information: ((conses 16 984879 633622) (symbols 48 62657 9) (strings 32 304460 91596) (string-bytes 1 9630727) (vectors 16 189334) (vector-slots 8 3198927 648189) (floats 8 710 1136) (intervals 56 14286 482) (buffers 984 91)) -- Manuel Giraud From debbugs-submit-bounces@debbugs.gnu.org Fri Jun 02 11:26:47 2023 Received: (at submit) by debbugs.gnu.org; 2 Jun 2023 15:26:47 +0000 Received: from localhost ([127.0.0.1]:40682 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1q56fv-0001bf-10 for submit@debbugs.gnu.org; Fri, 02 Jun 2023 11:26:47 -0400 Received: from lists.gnu.org ([209.51.188.17]:33322) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1q56ft-0001bU-9T for submit@debbugs.gnu.org; Fri, 02 Jun 2023 11:26:46 -0400 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 1q56fr-00035I-6j for bug-gnu-emacs@gnu.org; Fri, 02 Jun 2023 11:26:43 -0400 Received: from ledu-giraud.fr ([51.159.28.247]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1q56fp-0007uF-Dr for bug-gnu-emacs@gnu.org; Fri, 02 Jun 2023 11:26:42 -0400 DKIM-Signature: v=1; a=ed25519-sha256; c=simple/simple; s=ed25519; bh=GeoeKJQ5 htJ6MYAm7ToCORilvN/kTKxNRxuZRU8Z2mc=; h=date:references:in-reply-to: subject:cc:to:from; d=ledu-giraud.fr; b=BQ6Evr224x0WH8kaq2EitcRK1GcAvg dOBSOdQ+G3FtF8SeKvzWD7WS2bNq4IztnjDSwu2qCbTyn6EURPf0ZECw== DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; s=rsa; bh=GeoeKJQ5htJ6MYAm 7ToCORilvN/kTKxNRxuZRU8Z2mc=; h=date:references:in-reply-to:subject: cc:to:from; d=ledu-giraud.fr; b=F+YMlpHVKjAdo+xbiQzbH/GP15uFDfyBy41YFN Pgzv3Ga0QF/M3T/shN+rHs0mbzaDq92w1XviVbO8i6/MWSthvYbm45m7Xza9N+f0p97jKr LPzVG6q0ESud/wHQDnV8qalvoEi76dMmXDiy6UuqWw0X0NBEEwa273uaoBEHx9hIxDnmyF TRHOPf00aTZNVyBdnExe8iaCnUVHCmeqCIBYHjDdxhqCieOOecrDDtFaWqgu5sQZOuibbu 6qmkafGALbVnsiyiAjD5JkaF5z22s50ZbSCXJs2b6vb3V00oiYZf02SEOgdpTW4BW04Sz1 ermVhDfa/8eG0xMhePc19/qA== Received: from computer ( [10.1.1.1]) by ledu-giraud.fr (OpenSMTPD) with ESMTPSA id 2ec2dc3d (TLSv1.3:TLS_AES_256_GCM_SHA384:256:NO); Fri, 2 Jun 2023 17:26:38 +0200 (CEST) From: Manuel Giraud To: bug-gnu-emacs@gnu.org Subject: Re: 30.0.50; Slow 'gnus-summary-refer-thread' In-Reply-To: <871qiu6m1f.fsf@ledu-giraud.fr> (Manuel Giraud's message of "Fri, 02 Jun 2023 15:17:32 +0200") References: <871qiu6m1f.fsf@ledu-giraud.fr> Date: Fri, 02 Jun 2023 17:26:37 +0200 Message-ID: <87leh128cy.fsf@ledu-giraud.fr> User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="=-=-=" Received-SPF: pass client-ip=51.159.28.247; envelope-from=manuel@ledu-giraud.fr; helo=ledu-giraud.fr X-Spam_score_int: -20 X-Spam_score: -2.1 X-Spam_bar: -- X-Spam_report: (-2.1 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01 autolearn=ham autolearn_force=no X-Spam_action: no action X-Spam-Score: -1.4 (-) X-Debbugs-Envelope-To: submit Cc: cohen@andy.bu.edu X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -2.4 (--) --=-=-= Content-Type: text/plain Hi, FWIW, the attached patch fixes the issue for me. -- Manuel Giraud --=-=-= Content-Type: text/x-patch Content-Disposition: attachment; filename=0001-Fix-gnus-summary-refer-thread-slowness.patch >From 4242e4f5a828af94036c3d4f6e21726dbff4dc48 Mon Sep 17 00:00:00 2001 From: Manuel Giraud Date: Fri, 2 Jun 2023 17:23:15 +0200 Subject: [PATCH] Fix 'gnus-summary-refer-thread' slowness --- lisp/gnus/gnus-sum.el | 1 - 1 file changed, 1 deletion(-) diff --git a/lisp/gnus/gnus-sum.el b/lisp/gnus/gnus-sum.el index 4effaa981ec..725f5a1a5c9 100644 --- a/lisp/gnus/gnus-sum.el +++ b/lisp/gnus/gnus-sum.el @@ -9029,7 +9029,6 @@ gnus-summary-refer-thread (id (mail-header-id header)) (gnus-inhibit-demon t) (gnus-summary-ignore-duplicates t) - (gnus-read-all-available-headers t) (gnus-refer-thread-use-search (if (or (null limit) (numberp limit)) gnus-refer-thread-use-search -- 2.40.0 --=-=-=-- From debbugs-submit-bounces@debbugs.gnu.org Fri Jun 02 19:32:52 2023 Received: (at submit) by debbugs.gnu.org; 2 Jun 2023 23:32:52 +0000 Received: from localhost ([127.0.0.1]:41019 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1q5EGJ-0003I3-Sp for submit@debbugs.gnu.org; Fri, 02 Jun 2023 19:32:52 -0400 Received: from lists.gnu.org ([209.51.188.17]:43220) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1q5EGF-0003Hs-CL for submit@debbugs.gnu.org; Fri, 02 Jun 2023 19:32:50 -0400 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 1q5EGF-0006t9-0o for bug-gnu-emacs@gnu.org; Fri, 02 Jun 2023 19:32:47 -0400 Received: from andy.bu.edu ([128.197.41.152]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1q5EGA-0003gx-Cz for bug-gnu-emacs@gnu.org; Fri, 02 Jun 2023 19:32:46 -0400 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 1q5EG4-0005DD-7W; Fri, 02 Jun 2023 19:32:37 -0400 From: Andrew Cohen To: Manuel Giraud Subject: Re: 30.0.50; Slow 'gnus-summary-refer-thread' In-Reply-To: <871qiu6m1f.fsf@ledu-giraud.fr> (Manuel Giraud's message of "Fri, 02 Jun 2023 15:17:32 +0200") Organization: Boston University References: <871qiu6m1f.fsf@ledu-giraud.fr> Date: Sat, 03 Jun 2023 07:32:26 +0800 Message-ID: <87bkhxl9th.fsf@ust.hk> User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain Received-SPF: pass client-ip=128.197.41.152; envelope-from=cohen@bu.edu; helo=andy.bu.edu X-Spam_score_int: -18 X-Spam_score: -1.9 X-Spam_bar: - X-Spam_report: (-1.9 / 5.0 requ) BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01 autolearn=ham autolearn_force=no X-Spam_action: no action X-Spam-Score: -1.6 (-) X-Debbugs-Envelope-To: submit Cc: bug-gnu-emacs@gnu.org, cohen@andy.bu.edu X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -2.6 (--) Dear Manuel: >>>>> "MG" == Manuel Giraud 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 From debbugs-submit-bounces@debbugs.gnu.org Sat Jun 03 09:23:32 2023 Received: (at submit) by debbugs.gnu.org; 3 Jun 2023 13:23:32 +0000 Received: from localhost ([127.0.0.1]:41814 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1q5REB-0002Mg-NT for submit@debbugs.gnu.org; Sat, 03 Jun 2023 09:23:32 -0400 Received: from lists.gnu.org ([209.51.188.17]:36206) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1q5RE9-0002MS-2z for submit@debbugs.gnu.org; Sat, 03 Jun 2023 09:23:30 -0400 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 1q5RE8-0006aQ-Hi for bug-gnu-emacs@gnu.org; Sat, 03 Jun 2023 09:23:28 -0400 Received: from ledu-giraud.fr ([51.159.28.247]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1q5RE4-0007Zn-D0 for bug-gnu-emacs@gnu.org; Sat, 03 Jun 2023 09:23:27 -0400 DKIM-Signature: v=1; a=ed25519-sha256; c=simple/simple; s=ed25519; bh=REC1Sw0e i24vvSAkEhRzd9doPECp64OiB5T4DZqasvk=; h=date:references:in-reply-to: subject:cc:to:from; d=ledu-giraud.fr; b=sE4mA08AV38f02JkBAdyP6sSJVcrfB 6yGWjqHLs5Y76ljCRRdspahxfBW/niYhcgtUpAtXCSZti089opTZ+MDw== DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; s=rsa; bh=REC1Sw0ei24vvSAk EhRzd9doPECp64OiB5T4DZqasvk=; h=date:references:in-reply-to:subject: cc:to:from; d=ledu-giraud.fr; b=GNvNWzy6LBa9v+HtE2Mb3F4JHv3YPqMwgekkP1 bhEswofNQPtaSrvW695ZmL1enB+Xqh91FdzS1tc3nGcaeOG4zqR5da9Iikqs0PkXfahhn8 EVTLa8Q46uJUkxDDTARBKTcTIWNvU7HXuPzIwn63PDOZQXcqG636rjmVq3EoWwTsBHgTjD 5mky/cXwIhaxjo/O+5FbQbMSeqMcQyTfiKlRShowhH4+HfY4TM0OoPlHJEkL1nkRyHoqIB 9POBtTyJ4EGXve/N9GxaC9V14YnGJSHocLVdNvkDfgwvZT1RHjDm/iRguLmrwWuMJ3u54N +kPX4srO+bug6bVJf7xoxTlQ== Received: from computer ( [10.1.1.1]) by ledu-giraud.fr (OpenSMTPD) with ESMTPSA id 7d94f230 (TLSv1.3:TLS_AES_256_GCM_SHA384:256:NO); Sat, 3 Jun 2023 15:23:18 +0200 (CEST) From: Manuel Giraud To: Andrew Cohen Subject: Re: 30.0.50; Slow 'gnus-summary-refer-thread' In-Reply-To: <87bkhxl9th.fsf@ust.hk> (Andrew Cohen's message of "Sat, 03 Jun 2023 07:32:26 +0800") References: <871qiu6m1f.fsf@ledu-giraud.fr> <87bkhxl9th.fsf@ust.hk> Date: Sat, 03 Jun 2023 15:23:17 +0200 Message-ID: <87ilc44r3u.fsf@ledu-giraud.fr> User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain Received-SPF: pass client-ip=51.159.28.247; envelope-from=manuel@ledu-giraud.fr; helo=ledu-giraud.fr X-Spam_score_int: -20 X-Spam_score: -2.1 X-Spam_bar: -- X-Spam_report: (-2.1 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01 autolearn=ham autolearn_force=no X-Spam_action: no action X-Spam-Score: -1.4 (-) X-Debbugs-Envelope-To: submit Cc: bug-gnu-emacs@gnu.org, cohen@andy.bu.edu X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -2.4 (--) Andrew Cohen writes: [...] > Can you tell me (for circumstances where the referral is slow): Hi Andrew, > 1. What kind of group and the backend used in the group from which you > did the referral (imap, nntp, etc) I'm retrieving my mail via IMAP into a local nnml backend. This is in such group that I witness the slowdown. I have not tested on any other backend. > 2. What search engine are you using (imap, notmuch, etc) I have setup notmuch onto the default nnml directory and set 'gnus-select-method' as follow: --8<---------------cut here---------------start------------->8--- (setq gnus-select-method '(nnml "" (gnus-search-engine gnus-search-notmuch))) --8<---------------cut here---------------end--------------->8--- > 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? I have let 'gnus-refer-thread-use-search' to its default NIL value. My search was restricted to a single (mail) group and, previously, I was doing the same thread referral search on the same group. Thanks and hope this helps. -- Manuel Giraud From debbugs-submit-bounces@debbugs.gnu.org Thu Jun 15 01:55:15 2023 Received: (at 63842) by debbugs.gnu.org; 15 Jun 2023 05:55:15 +0000 Received: from localhost ([127.0.0.1]:45977 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1q9fww-0006lN-MD for submit@debbugs.gnu.org; Thu, 15 Jun 2023 01:55:15 -0400 Received: from eggs.gnu.org ([209.51.188.92]:42838) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1q9fwu-0006l7-D9 for 63842@debbugs.gnu.org; Thu, 15 Jun 2023 01:55:13 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1q9fwn-0004Sx-JZ; Thu, 15 Jun 2023 01:55:05 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date: mime-version; bh=i0iM1bYW2vHSyXhZIxTZqaA0gg/72i+qmt26Qm3DotA=; b=pOV21xBru4/y 9IknxyGCFNK2qXEwrv85+piI+sYZQ2MsSlwcYK5biIr7TQr+ViqrECeNutZNCeADXPeAqX9QX1Yw+ qUv15uQJRLJuyMzJFgoQQYcrV2Xgdrnit+0w8A2y2P7ceYKLwWfjYKiof7PfZnMjz2lwT5dpYluhO UdvprWg16CK91eQT4yUUCEajyjY0WUHfLeFHcecAltCX5HMonxcw3/fS2hOpito1Qtj9/QgnkFkZz ZlKDF3RbV/IRC0EJIEuMTiOYqLIaiLg7KoCrb/4hxDyu5iAxF3fC7TmxS/fCMRxa+QG6jU9ZmrQsn 9wZ6CXC4mF1TllmFih32MA==; Received: from [87.69.77.57] (helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1q9fwk-00026W-PI; Thu, 15 Jun 2023 01:55:04 -0400 Date: Thu, 15 Jun 2023 08:55:24 +0300 Message-Id: <831qiduv5f.fsf@gnu.org> From: Eli Zaretskii To: Manuel Giraud In-Reply-To: <87ilc44r3u.fsf@ledu-giraud.fr> (bug-gnu-emacs@gnu.org) Subject: Re: bug#63842: 30.0.50; Slow 'gnus-summary-refer-thread' References: <871qiu6m1f.fsf@ledu-giraud.fr> <87bkhxl9th.fsf@ust.hk> <87ilc44r3u.fsf@ledu-giraud.fr> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 63842 Cc: cohen@bu.edu, 63842@debbugs.gnu.org, cohen@andy.bu.edu X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) Ping! Can we revive this and solve the issue, please? > Cc: 63842@debbugs.gnu.org, cohen@andy.bu.edu > Date: Sat, 03 Jun 2023 15:23:17 +0200 > From: Manuel Giraud via "Bug reports for GNU Emacs, > the Swiss army knife of text editors" > > Andrew Cohen writes: > > [...] > > > Can you tell me (for circumstances where the referral is slow): > > Hi Andrew, > > > 1. What kind of group and the backend used in the group from which you > > did the referral (imap, nntp, etc) > > I'm retrieving my mail via IMAP into a local nnml backend. This is in > such group that I witness the slowdown. I have not tested on any other > backend. > > > 2. What search engine are you using (imap, notmuch, etc) > > I have setup notmuch onto the default nnml directory and set > 'gnus-select-method' as follow: > --8<---------------cut here---------------start------------->8--- > (setq gnus-select-method '(nnml "" (gnus-search-engine gnus-search-notmuch))) > --8<---------------cut here---------------end--------------->8--- > > > 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? > > I have let 'gnus-refer-thread-use-search' to its default NIL value. My > search was restricted to a single (mail) group and, previously, I was > doing the same thread referral search on the same group. > > Thanks and hope this helps. > -- > Manuel Giraud > > > > From debbugs-submit-bounces@debbugs.gnu.org Thu Jun 15 13:59:49 2023 Received: (at 63842) by debbugs.gnu.org; 15 Jun 2023 17:59:49 +0000 Received: from localhost ([127.0.0.1]:47887 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1q9rG9-0006LA-8U for submit@debbugs.gnu.org; Thu, 15 Jun 2023 13:59:49 -0400 Received: from ledu-giraud.fr ([51.159.28.247]:40924) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1q9rG6-0006Ky-Cn for 63842@debbugs.gnu.org; Thu, 15 Jun 2023 13:59:47 -0400 DKIM-Signature: v=1; a=ed25519-sha256; c=simple/simple; s=ed25519; bh=DpRkEJTO M+RUjcE5LW/oqAOhajiuNduD+p9BgxvuGBU=; h=date:references:in-reply-to: subject:cc:to:from; d=ledu-giraud.fr; b=KDiRmDvXwxfeFsx4CfrldJD1EcaOwH zDGT9f3Xvp1tSI1p/qceQnJrsJtSM/CK6A6DRvv3Vu6CmhMVm7HfghBQ== DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; s=rsa; bh=DpRkEJTOM+RUjcE5 LW/oqAOhajiuNduD+p9BgxvuGBU=; h=date:references:in-reply-to:subject: cc:to:from; d=ledu-giraud.fr; b=Y8AC5S6XfQ6msKIhtN1T53J4RlZm79aw8e8PO0 xddrKa4Z+1+vGxNlWkSWD3qcsCufwV1AcIA7TVojbqBX2noiyAGOJvnQ5cEzG+yIrBxYJD XU7Kwcq7K64nX7HLC9wGS8FOfojv9EbzlQisczy+VdMLglFoOpCUnHicYP8P4sxqhxUw9X G97zIW+EsqdY3RQI7CGjAeYlFzQvt3EAFWyFZTayzbsUhGrTrJyzlKGyQilP+DWMjFnubo qKsFFwWTki2FU3oM0myX5acYlAMShUdk5xcc9/SNcQEopQLgZaiq55u324k1UsEqxodyGA yXkGeRu89NTJKQGFCHgClqgA== Received: from computer ( [10.1.1.1]) by ledu-giraud.fr (OpenSMTPD) with ESMTPSA id eda9705c (TLSv1.3:TLS_AES_256_GCM_SHA384:256:NO); Thu, 15 Jun 2023 19:59:44 +0200 (CEST) From: Manuel Giraud To: Eli Zaretskii Subject: Re: bug#63842: 30.0.50; Slow 'gnus-summary-refer-thread' In-Reply-To: <831qiduv5f.fsf@gnu.org> (Eli Zaretskii's message of "Thu, 15 Jun 2023 08:55:24 +0300") References: <871qiu6m1f.fsf@ledu-giraud.fr> <87bkhxl9th.fsf@ust.hk> <87ilc44r3u.fsf@ledu-giraud.fr> <831qiduv5f.fsf@gnu.org> Date: Thu, 15 Jun 2023 19:59:43 +0200 Message-ID: <871qicr4hc.fsf@ledu-giraud.fr> User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: -0.0 (/) X-Debbugs-Envelope-To: 63842 Cc: cohen@bu.edu, 63842@debbugs.gnu.org, cohen@andy.bu.edu X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) Eli Zaretskii writes: > Ping! Can we revive this and solve the issue, please? I'm trying to investigate it. -- Manuel Giraud From debbugs-submit-bounces@debbugs.gnu.org Fri Jun 16 06:36:54 2023 Received: (at 63842) by debbugs.gnu.org; 16 Jun 2023 10:36:54 +0000 Received: from localhost ([127.0.0.1]:48667 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qA6p4-0002Bx-38 for submit@debbugs.gnu.org; Fri, 16 Jun 2023 06:36:54 -0400 Received: from ledu-giraud.fr ([51.159.28.247]:42364) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qA6p2-0002Bp-8m for 63842@debbugs.gnu.org; Fri, 16 Jun 2023 06:36:53 -0400 DKIM-Signature: v=1; a=ed25519-sha256; c=simple/simple; s=ed25519; bh=js3+NvKi pEVb8Yp7CKJXhl3p/rR1tghjvHEQiFkQL6E=; h=date:references:in-reply-to: subject:cc:to:from; d=ledu-giraud.fr; b=6nxme/1dw2bgvmIIY99O9suDjVhACE 7GDCkomIEinQ5fWtMbiwv/9p2TXJ818nbldjQ4nnmapQKwcov3hBStAQ== DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; s=rsa; bh=js3+NvKipEVb8Yp7 CKJXhl3p/rR1tghjvHEQiFkQL6E=; h=date:references:in-reply-to:subject: cc:to:from; d=ledu-giraud.fr; b=gS5pOBLW96+I4Xa1tBhhUhEY+5LdAJ2QqJPViU eD0as/4gYkQb4PWH8Xm/VbQS7ECpXtVvCBu0WH6P49xcu5GKZUBHDc3xyEcp+JM0cqbILA kipuNdivNJZBdzCDEnIMabDzj/H5eDIMztYPBJYNUZZI42HvOqQT+hS2IeoHFnRybszg99 1hIzcp74vY6YErqSznoQMQMQT6T6NvFHTD8KBdS3FIlFTqEoCsEUB4MOuE4Lg6ofyxbxx6 olGLMTRZ19t9qMchcFp9YIOZcYiNF+iPbq4Z+uku65kwiuf+I9f9kaIny6D36UjeEHFxMx wacrhcp3aQfsRz7Uri1+qJoA== Received: from computer ( [10.1.1.1]) by ledu-giraud.fr (OpenSMTPD) with ESMTPSA id 8d732998 (TLSv1.3:TLS_AES_256_GCM_SHA384:256:NO); Fri, 16 Jun 2023 12:36:50 +0200 (CEST) From: Manuel Giraud To: Eli Zaretskii Subject: Re: bug#63842: 30.0.50; Slow 'gnus-summary-refer-thread' In-Reply-To: <831qiduv5f.fsf@gnu.org> (Eli Zaretskii's message of "Thu, 15 Jun 2023 08:55:24 +0300") References: <871qiu6m1f.fsf@ledu-giraud.fr> <87bkhxl9th.fsf@ust.hk> <87ilc44r3u.fsf@ledu-giraud.fr> <831qiduv5f.fsf@gnu.org> Date: Fri, 16 Jun 2023 12:36:48 +0200 Message-ID: <87352rr8vz.fsf@ledu-giraud.fr> User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="=-=-=" X-Spam-Score: -0.0 (/) X-Debbugs-Envelope-To: 63842 Cc: cohen@bu.edu, 63842@debbugs.gnu.org, cohen@andy.bu.edu X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) --=-=-= Content-Type: text/plain Hi, So here is the crux of this issue. When using 'gnus-summary-refer-thread' in a nnml group, Emacs ends up calling 'gnus-get-newsgroup-headers-xover' (via 'gnus-fetch-headers'). AFAIU in this function when 'gnus-read-all-available-headers' is t, Emacs will parse *all* of the " *nntp*" buffer content. In my case, this buffer is quite big (about 50k lines and 23MiB) hence the slowness. BTW, I also have examples where 'gnus-summary-refer-thread' gives me some false positives (eg., not the same thread but part of the subject matching) I don't know how to proceed except from unsetting 'gnus-read-all-available-headers' for nnml backends (see attached patch). -- Manuel Giraud --=-=-= Content-Type: text/x-patch Content-Disposition: attachment; filename=0001-Do-not-read-all-headers-for-nnml-groups.patch >From 170cc2f96ebc606c25d85e345f9f9196fe6a7f33 Mon Sep 17 00:00:00 2001 From: Manuel Giraud Date: Fri, 16 Jun 2023 12:20:32 +0200 Subject: [PATCH] Do not read all headers for nnml groups --- lisp/gnus/gnus-sum.el | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/lisp/gnus/gnus-sum.el b/lisp/gnus/gnus-sum.el index 4effaa981ec..14da8735e88 100644 --- a/lisp/gnus/gnus-sum.el +++ b/lisp/gnus/gnus-sum.el @@ -9029,7 +9029,8 @@ gnus-summary-refer-thread (id (mail-header-id header)) (gnus-inhibit-demon t) (gnus-summary-ignore-duplicates t) - (gnus-read-all-available-headers t) + (gnus-read-all-available-headers + (not (eq (car (gnus-find-method-for-group group)) 'nnml))) (gnus-refer-thread-use-search (if (or (null limit) (numberp limit)) gnus-refer-thread-use-search -- 2.40.0 --=-=-=-- From debbugs-submit-bounces@debbugs.gnu.org Fri Jun 16 19:37:47 2023 Received: (at 63842) by debbugs.gnu.org; 16 Jun 2023 23:37:47 +0000 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 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 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 From: Andrew Cohen To: Manuel Giraud Subject: Re: bug#63842: 30.0.50; Slow 'gnus-summary-refer-thread' In-Reply-To: <87352rr8vz.fsf@ledu-giraud.fr> (Manuel Giraud's message of "Fri, 16 Jun 2023 12:36:48 +0200") References: <871qiu6m1f.fsf@ledu-giraud.fr> <87bkhxl9th.fsf@ust.hk> <87ilc44r3u.fsf@ledu-giraud.fr> <831qiduv5f.fsf@gnu.org> <87352rr8vz.fsf@ledu-giraud.fr> Date: Sat, 17 Jun 2023 07:37:28 +0800 Message-ID: <87fs6rashz.fsf@ust.hk> User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain 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 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 63842 Cc: cohen@bu.edu, Eli Zaretskii , 63842@debbugs.gnu.org, cohen@andy.bu.edu X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) 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 From debbugs-submit-bounces@debbugs.gnu.org Sat Jun 17 18:16:35 2023 Received: (at 63842) by debbugs.gnu.org; 17 Jun 2023 22:16:35 +0000 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 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== 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) From: Manuel Giraud To: Andrew Cohen Subject: Re: bug#63842: 30.0.50; Slow 'gnus-summary-refer-thread' In-Reply-To: <87fs6rashz.fsf@ust.hk> (Andrew Cohen's message of "Sat, 17 Jun 2023 07:37:28 +0800") 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> Date: Sun, 18 Jun 2023 00:16:26 +0200 Message-ID: <87352ppwed.fsf@ledu-giraud.fr> User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: -0.0 (/) X-Debbugs-Envelope-To: 63842 Cc: Eli Zaretskii , 63842@debbugs.gnu.org, cohen@andy.bu.edu X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) 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 From debbugs-submit-bounces@debbugs.gnu.org Sat Jun 17 20:46:03 2023 Received: (at 63842) by debbugs.gnu.org; 18 Jun 2023 00:46:03 +0000 Received: from localhost ([127.0.0.1]:52839 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qAgYM-0000Q8-Az for submit@debbugs.gnu.org; Sat, 17 Jun 2023 20:46:02 -0400 Received: from andy.bu.edu ([128.197.41.152]:36176) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qAgYK-0000Pk-8n for 63842@debbugs.gnu.org; Sat, 17 Jun 2023 20:46:01 -0400 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 1qAgYB-0005qr-UR; Sat, 17 Jun 2023 20:45:54 -0400 From: Andrew Cohen To: Manuel Giraud Subject: Re: bug#63842: 30.0.50; Slow 'gnus-summary-refer-thread' In-Reply-To: <87352ppwed.fsf@ledu-giraud.fr> (Manuel Giraud's message of "Sun, 18 Jun 2023 00:16:26 +0200") 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> <87352ppwed.fsf@ledu-giraud.fr> Date: Sun, 18 Jun 2023 08:45:41 +0800 Message-ID: <87ttv54myy.fsf@ust.hk> User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain 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: 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 [...] 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 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 63842 Cc: Andrew Cohen , Eli Zaretskii , 63842@debbugs.gnu.org, cohen@andy.bu.edu X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) 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). Best, Andy >>>>> "MG" == Manuel Giraud writes: MG> Andrew Cohen writes: >> Sorry, I have gotten busy with other things at the moment. MG> 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? MG> I think in a nnml group the nntp buffer is populated with the MG> content of the ".overview" file. In this particular group, I MG> have thousands of messages and I think that explains the size of MG> 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? MG> As we are talking about 'gnus-summary-refer-thread', I guess MG> that it is expected that the nntp buffer is filled with this MG> content. A regular query (with 'G G') is still fast, so I think MG> 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"). MG> In my case, Emacs is using the 'gnus-search-thread' branch and MG> ends up calling 'gnus-get-newsgroup-headers-xover' which is the MG> function that parses all the nntp buffer content. MG> BTW, I also have examples where 'gnus-summary-refer-thread' MG> gives me some false positives (eg., not the same thread but part MG> of the subject 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. MG> Ok, thanks for the explanation and FWIW, my MG> 'gnus-summary-thread-gathering-function' is already set to MG> 'gnus-gather-threads-by-references. MG> Best regards, -- Manuel Giraud -- Andrew Cohen Director, HKUST Jockey Club Institute for Advanced Study Lam Woo Foundation Professor and Chair Professor of Physics The Hong Kong University of Science and Technology From debbugs-submit-bounces@debbugs.gnu.org Sun Jun 18 16:57:38 2023 Received: (at 63842) by debbugs.gnu.org; 18 Jun 2023 20:57:38 +0000 Received: from localhost ([127.0.0.1]:55066 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qAzSr-0007Yd-Tn for submit@debbugs.gnu.org; Sun, 18 Jun 2023 16:57:38 -0400 Received: from ledu-giraud.fr ([51.159.28.247]:5465) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qAzSp-0007YU-Ke for 63842@debbugs.gnu.org; Sun, 18 Jun 2023 16:57:36 -0400 DKIM-Signature: v=1; a=ed25519-sha256; c=simple/simple; s=ed25519; bh=D57DYWQ9 qKltrpYSMougrasV0LXvLY5Ns5ncX5DZFC4=; h=date:references:in-reply-to: subject:cc:to:from; d=ledu-giraud.fr; b=HJSDXDt9O1kRJW2pgG8YbjqFnFbvvn xDmaTyhnlLgNJquLn7KO3RGXOqi4eenfqB7v9R9q3tqjWwqdn3HJGACA== DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; s=rsa; bh=D57DYWQ9qKltrpYS MougrasV0LXvLY5Ns5ncX5DZFC4=; h=date:references:in-reply-to:subject: cc:to:from; d=ledu-giraud.fr; b=W0y738L/8ESpn0aRxgXhhvmsuSsgffjlusUiYw 6UJXuSAjZPdyVvN4j/IOISAdanw8DIxrfQUSoIy85ahUfZhUe9gcHxkFSXNvWv7ENoik48 roJsJAPbROwuf9Tl28iuMxbFmwm+ahzybkXvIYvHQ62wnNFC6tEbYDXlKSJBC0aGWMQLIR vgOSiKYt30coaSvhqcrNDC87MsxE0Xc4Sg4L+XFH5AGJn2c1oRID08LM7CwwhBZ8puvtbG dlOy0LmILsBSoa55pcPH1ImQ4U3Io7UGxFkcWJoBNoJZP2E+GxHTTarbrOXk29n6h45WW+ b53MqrDfLLZHF20RpbYi0NUw== Received: from computer ( [10.1.1.1]) by ledu-giraud.fr (OpenSMTPD) with ESMTPSA id e72c7e3a (TLSv1.3:TLS_AES_256_GCM_SHA384:256:NO); Sun, 18 Jun 2023 22:57:33 +0200 (CEST) From: Manuel Giraud To: Andrew Cohen Subject: Re: bug#63842: 30.0.50; Slow 'gnus-summary-refer-thread' In-Reply-To: <87ttv54myy.fsf@ust.hk> (Andrew Cohen's message of "Sun, 18 Jun 2023 08:45:41 +0800") 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> <87352ppwed.fsf@ledu-giraud.fr> <87ttv54myy.fsf@ust.hk> Date: Sun, 18 Jun 2023 22:57:32 +0200 Message-ID: <87o7lco5dv.fsf@ledu-giraud.fr> User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: -0.0 (/) X-Debbugs-Envelope-To: 63842 Cc: Eli Zaretskii , 63842@debbugs.gnu.org, cohen@andy.bu.edu X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) Andrew Cohen 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 From debbugs-submit-bounces@debbugs.gnu.org Mon Jun 19 08:58:34 2023 Received: (at 63842) by debbugs.gnu.org; 19 Jun 2023 12:58:34 +0000 Received: from localhost ([127.0.0.1]:55794 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qBESo-0006Xa-3k for submit@debbugs.gnu.org; Mon, 19 Jun 2023 08:58:34 -0400 Received: from andy.bu.edu ([128.197.41.152]:36342) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qBESm-0006XN-4x for 63842@debbugs.gnu.org; Mon, 19 Jun 2023 08:58:32 -0400 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 1qBESf-0004D0-7R; Mon, 19 Jun 2023 08:58:26 -0400 From: Andrew Cohen To: Manuel Giraud Subject: Re: bug#63842: 30.0.50; Slow 'gnus-summary-refer-thread' In-Reply-To: <87o7lco5dv.fsf@ledu-giraud.fr> (Manuel Giraud's message of "Sun, 18 Jun 2023 22:57:32 +0200") 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> <87352ppwed.fsf@ledu-giraud.fr> <87ttv54myy.fsf@ust.hk> <87o7lco5dv.fsf@ledu-giraud.fr> Date: Mon, 19 Jun 2023 20:58:15 +0800 Message-ID: <87bkhbpq1k.fsf@ust.hk> User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain 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: >>>>> "MG" == Manuel Giraud writes: MG> Andrew Cohen writes: >> OK, I think I understand the problem. [...] 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 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 63842 Cc: Andrew Cohen , Eli Zaretskii , 63842@debbugs.gnu.org, cohen@andy.bu.edu X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) >>>>> "MG" == Manuel Giraud writes: MG> Andrew Cohen 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). 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 to Manuel for figuring out the error. I'll push the fix shortly. Best, Andy -- Andrew Cohen From debbugs-submit-bounces@debbugs.gnu.org Mon Jun 19 11:44:44 2023 Received: (at 63842) by debbugs.gnu.org; 19 Jun 2023 15:44:44 +0000 Received: from localhost ([127.0.0.1]:57067 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qBH3b-0003CD-TS for submit@debbugs.gnu.org; Mon, 19 Jun 2023 11:44:44 -0400 Received: from ledu-giraud.fr ([51.159.28.247]:25253) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qBH3Y-0003C3-M6 for 63842@debbugs.gnu.org; Mon, 19 Jun 2023 11:44:42 -0400 DKIM-Signature: v=1; a=ed25519-sha256; c=simple/simple; s=ed25519; bh=VfJADMgX v8oi4r2DcV8ZYv0dceWrZzRCtslQSr3mZCs=; h=date:references:in-reply-to: subject:cc:to:from; d=ledu-giraud.fr; b=j6mOmqbDbsU3ub0lhLOgtDWYUcOn1L Cc7Ao9dkqTKEMoz6GuGCFo12dEupGKdN6rAtcP9qUNpBLD40gp0/xmAg== DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; s=rsa; bh=VfJADMgXv8oi4r2D cV8ZYv0dceWrZzRCtslQSr3mZCs=; h=date:references:in-reply-to:subject: cc:to:from; d=ledu-giraud.fr; b=h9vfxyTF0wa+tubb3QzSi9aB8O/kBLWn3QfzrN r0FmdxBQDYT8le73LIvqRF71KPB6thit1uw9mGgVU8iLEQiYFR19kJK/0okNXqyevL0Wbh NAPFoVCuYWCeWZ9YaeWqU/S5jKFtgjfOe5zUvzuera3CGDeeKc4RBzuoXyN49ZoO939gE2 bssr9V2v6YNaKwsfWLcbF0cb/JKdp1SPUq+6mSKqf9RrBboWd5DHnpXuiZh4Ww8BBvOeRD UgQoCcJ9zhXedY6HuomRsRVaeuaDipkLGeqG/D3yfKqBOJ0awKnofANEyC5Qr5PK09yucV xIKFfDNyhMdv2I0Pui8eJk6w== Received: from computer ( [10.1.1.1]) by ledu-giraud.fr (OpenSMTPD) with ESMTPSA id 4f725805 (TLSv1.3:TLS_AES_256_GCM_SHA384:256:NO); Mon, 19 Jun 2023 17:44:38 +0200 (CEST) From: Manuel Giraud To: Andrew Cohen Subject: Re: bug#63842: 30.0.50; Slow 'gnus-summary-refer-thread' In-Reply-To: <87bkhbpq1k.fsf@ust.hk> (Andrew Cohen's message of "Mon, 19 Jun 2023 20:58:15 +0800") 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> <87352ppwed.fsf@ledu-giraud.fr> <87ttv54myy.fsf@ust.hk> <87o7lco5dv.fsf@ledu-giraud.fr> <87bkhbpq1k.fsf@ust.hk> Date: Mon, 19 Jun 2023 17:44:37 +0200 Message-ID: <874jn3o3ru.fsf@ledu-giraud.fr> User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: -0.0 (/) X-Debbugs-Envelope-To: 63842 Cc: Eli Zaretskii , 63842@debbugs.gnu.org, cohen@andy.bu.edu X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) Andrew Cohen writes: >>>>>> "MG" == Manuel Giraud writes: > > MG> Andrew Cohen 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 From debbugs-submit-bounces@debbugs.gnu.org Fri Jun 23 06:00:52 2023 Received: (at 63842) by debbugs.gnu.org; 23 Jun 2023 10:00:52 +0000 Received: from localhost ([127.0.0.1]:37712 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qCdb1-0006qo-Pw for submit@debbugs.gnu.org; Fri, 23 Jun 2023 06:00:52 -0400 Received: from ledu-giraud.fr ([51.159.28.247]:20740) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qCdaz-0006qd-4y for 63842@debbugs.gnu.org; Fri, 23 Jun 2023 06:00:50 -0400 DKIM-Signature: v=1; a=ed25519-sha256; c=simple/simple; s=ed25519; bh=v/yXcBrQ OXcmX5VrdrQNy9t6+7W/ciFwEOU3BlS5Y68=; h=date:references:in-reply-to: subject:cc:to:from; d=ledu-giraud.fr; b=3zPO9/CBoIpPjEALRu85Q2fLqIxRdm vP4I8BuNWtbqOgbIec+l+/NJxR54ZIwDl7n5YMRPW0htUtWUJvGe8dBw== DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; s=rsa; bh=v/yXcBrQOXcmX5Vr drQNy9t6+7W/ciFwEOU3BlS5Y68=; h=date:references:in-reply-to:subject: cc:to:from; d=ledu-giraud.fr; b=gP+fTqwezFyveJRXK/BMAQtxRW0bLBYxMpPZYC 3s8+uwL3iTxjpr5EKdz3xU8uqKOOw8KbBBuTrJCUrMKNSZoj3gcPOeCbvgDcuxtshnZuz+ wy/WwWJovxid7tDEJHvAM0l2/Fz7GmkkJWI41of0AzxXtDEd8r/H+iBAPbLh0UewweAKNI FYE57TAiqoOidnEvhGrZsXwESLULT4oVvVVy0VsNaNWI/zxa+F01EYJuQL/B4qotoXF17O R7sYEgoCxlbjXi1EbFkB0LF/iNixX/Tg/P/XCFnkuonSQfSbo1xLqYdFEnLDSLnLm4RMrS z5h84wDCJqm814aitRezDDXw== Received: from computer ( [10.1.1.1]) by ledu-giraud.fr (OpenSMTPD) with ESMTPSA id cb765adc (TLSv1.3:TLS_AES_256_GCM_SHA384:256:NO); Fri, 23 Jun 2023 12:00:46 +0200 (CEST) From: Manuel Giraud To: Andrew Cohen Subject: Re: bug#63842: 30.0.50; Slow 'gnus-summary-refer-thread' In-Reply-To: <874jn3o3ru.fsf@ledu-giraud.fr> (Manuel Giraud's message of "Mon, 19 Jun 2023 17:44:37 +0200") 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> <87352ppwed.fsf@ledu-giraud.fr> <87ttv54myy.fsf@ust.hk> <87o7lco5dv.fsf@ledu-giraud.fr> <87bkhbpq1k.fsf@ust.hk> <874jn3o3ru.fsf@ledu-giraud.fr> Date: Fri, 23 Jun 2023 12:00:45 +0200 Message-ID: <87352izeeq.fsf@ledu-giraud.fr> User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: -0.0 (/) X-Debbugs-Envelope-To: 63842 Cc: Eli Zaretskii , 63842@debbugs.gnu.org, cohen@andy.bu.edu X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) Manuel Giraud writes: [...] >> 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. Hi Andrew, I have seen your patch and it works as expected. 'gnus-summary-refer-thread' is as fast as before for me. Thanks. -- Manuel Giraud From debbugs-submit-bounces@debbugs.gnu.org Sat Jul 01 04:24:43 2023 Received: (at 63842) by debbugs.gnu.org; 1 Jul 2023 08:24:43 +0000 Received: from localhost ([127.0.0.1]:56495 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qFVuM-0005EU-TF for submit@debbugs.gnu.org; Sat, 01 Jul 2023 04:24:43 -0400 Received: from eggs.gnu.org ([209.51.188.92]:44928) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qFVuK-0005ED-Qq for 63842@debbugs.gnu.org; Sat, 01 Jul 2023 04:24:41 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1qFVuC-0005Eh-Hd; Sat, 01 Jul 2023 04:24:32 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date: mime-version; bh=vnpLtm3bnEphTLb5mXNHyYki/WJAx7yCKyw42Ndtxp4=; b=WAT0n0CMsKg+ 0siU5KmAeNWWy/PWADcJneKXW0mxypF1lbJ4k/UN0MMY+Uc9wh66aES1zqIZ5HFQGc90i0i9seuJG IE9uBuaONoQlNP29pUc+pQV1ENvQ1/tkoJ7oMZhCysc0ZcpJ2mOuzhfRMR7z2h74iYThB3h8dz33t AodSHIGFihDDm4WiG2Lv3P0tTNo6NEVidzBr1WtjHqf/Jq0YNi7L+8KghU8sgGTZWrwJ9UI3X1eSo O5zE9935efznS1wbeSPlVao+JeiBfadDzCAYt/jBv0Z46S3myf4MBwbkeUv2yDiKh3w4yUiqeXVhV H5eVzrFVpE4PBwnA63Aa8w==; Received: from [87.69.77.57] (helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1qFVuB-0001xR-5w; Sat, 01 Jul 2023 04:24:32 -0400 Date: Sat, 01 Jul 2023 11:25:02 +0300 Message-Id: <83r0psqbs1.fsf@gnu.org> From: Eli Zaretskii To: Manuel Giraud In-Reply-To: <87352izeeq.fsf@ledu-giraud.fr> (message from Manuel Giraud on Fri, 23 Jun 2023 12:00:45 +0200) Subject: Re: bug#63842: 30.0.50; Slow 'gnus-summary-refer-thread' 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> <87352ppwed.fsf@ledu-giraud.fr> <87ttv54myy.fsf@ust.hk> <87o7lco5dv.fsf@ledu-giraud.fr> <87bkhbpq1k.fsf@ust.hk> <874jn3o3ru.fsf@ledu-giraud.fr> <87352izeeq.fsf@ledu-giraud.fr> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 63842 Cc: cohen@bu.edu, 63842@debbugs.gnu.org, cohen@andy.bu.edu X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > From: Manuel Giraud > Cc: Eli Zaretskii , 63842@debbugs.gnu.org, cohen@andy.bu.edu > Date: Fri, 23 Jun 2023 12:00:45 +0200 > > Manuel Giraud writes: > > [...] > > >> 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. > > Hi Andrew, > > I have seen your patch and it works as expected. > 'gnus-summary-refer-thread' is as fast as before for me. Thanks. Thanks. can the fix be installed and the bug closed then, please? From debbugs-submit-bounces@debbugs.gnu.org Sat Jul 01 05:48:44 2023 Received: (at 63842-done) by debbugs.gnu.org; 1 Jul 2023 09:48:44 +0000 Received: from localhost ([127.0.0.1]:56610 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qFXDg-0007eX-Gw for submit@debbugs.gnu.org; Sat, 01 Jul 2023 05:48:44 -0400 Received: from eggs.gnu.org ([209.51.188.92]:53188) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qFXDd-0007eH-Ky for 63842-done@debbugs.gnu.org; Sat, 01 Jul 2023 05:48:42 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1qFXDY-0000fU-6G; Sat, 01 Jul 2023 05:48:36 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date: mime-version; bh=38+ltCZ2DrXueKmxE3KBJS/n0/Aq4SZl09vPXEO7JMM=; b=e83hRIAskUGI iD/96Eke/f05EWgfiRv4arv/OrZhp+I1OzAVpheof0bbhx6yiLwaFVizjDlR7K8vfJtA4F1dQ9a2c sQgv8xiBWscW39CLHqqm25+RJur9AZfyp2CwxGIHEzMs3j65z/eByPxkT8QXpaUgkAEPiuxrbVIKj ChMS7c5m38m2x0uVaJseR8vq0rgK68mgYyy1mJVzuJ1GsWsTI438e8TMukoFRPEFQ5CBOga9xycbr IlZhlLXVdFZwCxQZ3ib2tqBLFsdFjbtMwrpbeaEbhnjzkPEkpRFGQpJknVCHvRBSthj/LH4EAXh6k /z0LU4cAZQkzkVNywYHxdw==; Received: from [87.69.77.57] (helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1qFXDX-0002yz-K8; Sat, 01 Jul 2023 05:48:35 -0400 Date: Sat, 01 Jul 2023 12:49:07 +0300 Message-Id: <838rc0q7vw.fsf@gnu.org> From: Eli Zaretskii To: Andrew Cohen In-Reply-To: <87edlsav34.fsf@ust.hk> (message from Andrew Cohen on Sat, 01 Jul 2023 16:34:39 +0800) Subject: Re: bug#63842: 30.0.50; Slow 'gnus-summary-refer-thread' 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> <87352ppwed.fsf@ledu-giraud.fr> <87ttv54myy.fsf@ust.hk> <87o7lco5dv.fsf@ledu-giraud.fr> <87bkhbpq1k.fsf@ust.hk> <874jn3o3ru.fsf@ledu-giraud.fr> <87352izeeq.fsf@ledu-giraud.fr> <83r0psqbs1.fsf@gnu.org> <87edlsav34.fsf@ust.hk> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 63842-done Cc: 63842-done@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > From: Andrew Cohen > Date: Sat, 01 Jul 2023 16:34:39 +0800 > > >>>>> "EZ" == Eli Zaretskii writes: > > >> From: Manuel Giraud Cc: Eli Zaretskii > >> , 63842@debbugs.gnu.org, cohen@andy.bu.edu Date: > >> Fri, 23 Jun 2023 12:00:45 +0200 > >> > >> Manuel Giraud writes: > >> > >> [...] > >> > >> >> 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. > >> > >> Hi Andrew, > >> > >> I have seen your patch and it works as expected. > >> 'gnus-summary-refer-thread' is as fast as before for me. Thanks. > > EZ> Thanks. can the fix be installed and the bug closed then, > EZ> please? > > Already installed (commit 1e13610b75718e7904f8af181fb73571639e1211). Bug > can be closed. Thanks, done. From unknown Sat Jun 21 03:11:49 2025 Received: (at fakecontrol) by fakecontrolmessage; To: internal_control@debbugs.gnu.org From: Debbugs Internal Request Subject: Internal Control Message-Id: bug archived. Date: Sat, 29 Jul 2023 11:24:09 +0000 User-Agent: Fakemail v42.6.9 # This is a fake control message. # # The action: # bug archived. thanks # This fakemail brought to you by your local debbugs # administrator