From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.io/gmane.emacs.gnus.general/57827 Path: main.gmane.org!not-for-mail From: Lloyd Zusman Newsgroups: gmane.emacs.gnus.general Subject: Re: Gnus vs Wanderlust Date: Thu, 03 Jun 2004 19:39:46 -0400 Sender: ding-owner@lists.math.uh.edu Message-ID: References: <87zn7mvrcl.fsf@tc-1-100.kawasaki.gol.ne.jp> <87u0xsrzod.fsf@tc-1-100.kawasaki.gol.ne.jp> NNTP-Posting-Host: deer.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: sea.gmane.org 1086306087 2008 80.91.224.253 (3 Jun 2004 23:41:27 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Thu, 3 Jun 2004 23:41:27 +0000 (UTC) Original-X-From: ding-owner+M6368@lists.math.uh.edu Fri Jun 04 01:41:17 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 1BW1ph-0000Da-00 for ; Fri, 04 Jun 2004 01:41:13 +0200 Original-Received: from localhost ([127.0.0.1] helo=lists.math.uh.edu) by malifon.math.uh.edu with smtp (Exim 3.20 #1) id 1BW1pO-0002B6-00; Thu, 03 Jun 2004 18:40:54 -0500 Original-Received: from util2.math.uh.edu ([129.7.128.23]) by malifon.math.uh.edu with esmtp (Exim 3.20 #1) id 1BW1pJ-0002B1-00 for ding@lists.math.uh.edu; Thu, 03 Jun 2004 18:40:49 -0500 Original-Received: from justine.libertine.org ([66.139.78.221] ident=postfix) by util2.math.uh.edu with esmtp (Exim 4.30) id 1BW1pI-0004Ua-9m for ding@lists.math.uh.edu; Thu, 03 Jun 2004 18:40:48 -0500 Original-Received: from main.gmane.org (main.gmane.org [80.91.224.249]) by justine.libertine.org (Postfix) with ESMTP id 93AC73A005F for ; Thu, 3 Jun 2004 18:40:47 -0500 (CDT) Original-Received: from list by main.gmane.org with local (Exim 3.35 #1 (Debian)) id 1BW1pG-0007tJ-00 for ; Fri, 04 Jun 2004 01:40:46 +0200 Original-Received: from hippo.asfast.com ([216.182.10.250]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 04 Jun 2004 01:40:46 +0200 Original-Received: from ljz by hippo.asfast.com with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 04 Jun 2004 01:40:46 +0200 X-Injected-Via-Gmane: http://gmane.org/ Original-To: ding@gnus.org Original-Lines: 50 Original-X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: hippo.asfast.com User-Agent: Gnus/5.110002 (No Gnus v0.2) Emacs/21.2 (gnu/linux) Cancel-Lock: sha1:O9yOtb2zhqUmmg4NuV3Wu9NXbVA= Precedence: bulk Xref: main.gmane.org gmane.emacs.gnus.general:57827 X-Report-Spam: http://spam.gmane.org/gmane.emacs.gnus.general:57827 Miles Bader writes: > colin.rafferty@morganstanley.com writes: >> 1. It does not cache summary layout information. When it builds a >> summary, it has to start from scratch. > > Is this actually a problem? Judging from what I see, the great bulk of > the time is _not_ in summary generation, but rather getting info from > the server (which is where the sparse-range problems show up too). Well, I found that Wanderlust, which seems to cache and incrementally update summaries, builds the summary buffer for a large (> 10000 messages) IMAP group much faster than Gnus does for the same IMAP group ... at least after the first time I enter the group when all the initial summary building and caching takes place. I understand that Wanderlust doesn't do as much of the fancy stuff that Gnus does, but I am another person who doesn't use those features in my IMAP groups. Perhaps this behavior could become a group-specific option in Gnus ... ??? > [My computer's pretty slow by contemporary standards too -- a 450MHz > pentium] > > I suppose one could try to cache and incrementally update summaries, but > summary-generation is already so fast, even for very large groups, that > it might make more sense to investigate whether it could be made even > faster (maybe even with some new emacs primitives). Well, I have empirical evidence that caching and incrementally updating summaries can indeed make the entry into a large IMAP group considerably faster. > Having `in between' summary generation might be nice too, especially > when just updating a summary buffer with M-g -- for instance, delete and > regenerate all threads where anything changed (message disappeared, > message added ...) would probably be very fast, as in a large group, > this would avoid regenerating most of the summary. Agreed. In fact, this is probably closer to what Wanderlust does. -- Lloyd Zusman ljz@asfast.com God bless you.