From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.io/gmane.emacs.gnus.general/58328 Path: main.gmane.org!not-for-mail From: Kevin Greiner Newsgroups: gmane.emacs.gnus.general Subject: Re: Gnus is very slow in displaying headers. Date: Mon, 23 Aug 2004 23:49:46 -0500 Sender: ding-owner@lists.math.uh.edu Message-ID: References: <4knii01atsa54v7dm0gs6taep3v1uoglj7@4ax.com> NNTP-Posting-Host: deer.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: sea.gmane.org 1093323182 20367 80.91.224.253 (24 Aug 2004 04:53:02 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Tue, 24 Aug 2004 04:53:02 +0000 (UTC) Original-X-From: ding-owner+M6869@lists.math.uh.edu Tue Aug 24 06:52:53 2004 Return-path: Original-Received: from malifon.math.uh.edu ([129.7.128.13]) by deer.gmane.org with esmtp (Exim 3.35 #1 (Debian)) id 1BzTIj-00049D-00 for ; Tue, 24 Aug 2004 06:52:53 +0200 Original-Received: from localhost ([127.0.0.1] helo=lists.math.uh.edu ident=lists) by malifon.math.uh.edu with smtp (Exim 3.20 #1) id 1BzTG3-0005Nt-00; Mon, 23 Aug 2004 23:50:07 -0500 Original-Received: from util2.math.uh.edu ([129.7.128.23]) by malifon.math.uh.edu with esmtp (Exim 3.20 #1) id 1BzTFv-0005Nj-00 for ding@lists.math.uh.edu; Mon, 23 Aug 2004 23:49:59 -0500 Original-Received: from justine.libertine.org ([66.139.78.221] ident=postfix) by util2.math.uh.edu with esmtp (Exim 4.30) id 1BzTFv-0006Kd-0i for ding@lists.math.uh.edu; Mon, 23 Aug 2004 23:49:59 -0500 Original-Received: from quimby.gnus.org (quimby.gnus.org [80.91.224.244]) by justine.libertine.org (Postfix) with ESMTP id 21A363A0034 for ; Mon, 23 Aug 2004 23:49:57 -0500 (CDT) Original-Received: from news by quimby.gnus.org with local (Exim 3.35 #1 (Debian)) id 1BzTFr-0003Ru-00 for ; Tue, 24 Aug 2004 06:49:55 +0200 Original-To: ding@gnus.org Original-Path: not-for-mail Original-Newsgroups: gnus.ding Original-Lines: 47 Original-NNTP-Posting-Host: ip-69-33-218-34.chi.megapath.net Original-X-Trace: quimby.gnus.org 1093322993 13261 69.33.218.34 (24 Aug 2004 04:49:53 GMT) Original-X-Complaints-To: usenet@quimby.gnus.org Original-NNTP-Posting-Date: Tue, 24 Aug 2004 04:49:53 +0000 (UTC) User-Agent: Gnus/5.110003 (No Gnus v0.3) Emacs/21.3.50 (windows-nt) Cancel-Lock: sha1:W80stQbqHY3OpTEAA1X6GZY1d9M= Precedence: bulk Xref: main.gmane.org gmane.emacs.gnus.general:58328 X-Report-Spam: http://spam.gmane.org/gmane.emacs.gnus.general:58328 Daniel M. writes: > Hello everybody, > > I noticed that even when I enter a group with a relatively small > amount of headers - in my case, 12000 for comp.lang.lisp, it takes > Gnus a very long time to thread/load them (headers are already in > the spool - they were downloaded previously by the Gnus) - 3 minutes > and 100% CPU for the duration of that period. > > Forte Agent, for example, has no problem with groups which > contain hundreds of thousands of headers - it takes merely a couple > of seconds to load them, so it is not a lack of memory/CPU cycles. > > Am I doing something wrong, or is it a fundamental issue (elisp is too > slow? something in the core of X/Emacs?) which renders Gnus unusable > for anything more then a very small groups? The problem is mostly likely due to your setting for gnus-summary-line-format. This is a string that describes the fields displayed for each line of the summary buffer. Internally, gnus compiles this string into an elisp expression that inserts an article into the buffer. The approach is infinitely customizable but not very optimizable. You might look in the manual under 'Summary Buffer Lines' to see if can identify a simplier string; one that meets your requirements yet offers better performance. > After searching the group for a similar questions, I saw an advice > to set nntp-marks-is-evil variable to 't', which I have done, but > it made no noticable difference. Right. Nothing to do with your problem. > I use Gnus 5.10.6 on Debian (precompiled package from unstable). > > BTW, listing of all active groups (zombie, killed groups - I am not > sure how I am supposed to call them. In effect, it is the list of all > groups carried by the server) also takes a lot of time - almost a full > minute, although there are only ~32000 groups and the file containing > them resides on the HD. I even tried to sort that file, but it didn't > help :(. I see the same thing, I just don't display the active list often enough to try to optimize it. Kevin