From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.io/gmane.emacs.gnus.general/25191 Path: main.gmane.org!not-for-mail From: Hannu Koivisto Newsgroups: gmane.emacs.gnus.general Subject: Re: overview file access when spooling and nnml/nnimap performance Date: 22 Sep 1999 18:32:33 +0300 Sender: owner-ding@hpc.uh.edu Message-ID: <87emfrufla.fsf@senstation.vvf.fi> References: <877lljawft.fsf@senstation.vvf.fi> NNTP-Posting-Host: coloc-standby.netfonds.no Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Trace: main.gmane.org 1035162623 12725 80.91.224.250 (21 Oct 2002 01:10:23 GMT) X-Complaints-To: usenet@main.gmane.org NNTP-Posting-Date: Mon, 21 Oct 2002 01:10:23 +0000 (UTC) Return-Path: Original-Received: from bart.math.uh.edu (bart.math.uh.edu [129.7.128.48]) by sclp3.sclp.com (8.8.5/8.8.5) with ESMTP id LAA02602 for ; Wed, 22 Sep 1999 11:34:58 -0400 (EDT) Original-Received: from sina.hpc.uh.edu (lists@Sina.HPC.UH.EDU [129.7.3.5]) by bart.math.uh.edu (8.9.1/8.9.1) with ESMTP id KAB13986; Wed, 22 Sep 1999 10:34:53 -0500 (CDT) Original-Received: by sina.hpc.uh.edu (TLB v0.09a (1.20 tibbs 1996/10/09 22:03:07)); Wed, 22 Sep 1999 10:35:16 -0500 (CDT) Original-Received: from sclp3.sclp.com (root@sclp3.sclp.com [204.252.123.139]) by sina.hpc.uh.edu (8.9.3/8.9.3) with ESMTP id KAA29045 for ; Wed, 22 Sep 1999 10:35:06 -0500 (CDT) Original-Received: from senstation.vvf.fi (senstation.vvf.fi [195.74.10.211]) by sclp3.sclp.com (8.8.5/8.8.5) with ESMTP id LAA02545 for ; Wed, 22 Sep 1999 11:33:05 -0400 (EDT) Original-Received: from azure by senstation.vvf.fi with local (Exim 3.03 #1 (Debian)) id 11ToNl-0001Pr-00; Wed, 22 Sep 1999 18:32:33 +0300 Original-To: ding@gnus.org In-Reply-To: Kai.Grossjohann@CS.Uni-Dortmund.DE's message of "22 Sep 1999 16:13:36 +0200" Original-Lines: 67 User-Agent: Gnus/5.070096 (Pterodactyl Gnus v0.96) Emacs/20.3 Precedence: list X-Majordomo: 1.94.jlt7 Xref: main.gmane.org gmane.emacs.gnus.general:25191 X-Report-Spam: http://spam.gmane.org/gmane.emacs.gnus.general:25191 Kai.Grossjohann@CS.Uni-Dortmund.DE (Kai Großjohann) writes: | I think nnimap is even slower than nnml because the NOV parsing done | by Gnus is so fast. In fact, nnimap now includes a NOV cache feature | which fetches overview info from the IMAP server only once. After | that, the overview information is stored in a file in ~/News and | subsequently fetched from there. Hm, I don't quite follow why this gives a reason why nnimap is even slower than nnml. After all, Gnus parses NOV stuff less in nnimap's case as it doesn't have to touch overview info when mail is getting spooled to folders -- IMAP server does that. It has to handle overview info when entering a group but that's same for nnml and nnimap, isn't it? Of course, without caching, that overview file would be read over network, but after all, I was more concerned about optimizing the spooling phase which in IMAP's case is handled on the background, like you say below. Perhaps there would be some way to get asynchronous external spooling directly to nnml folders too, but, unlike with nnmh, that would require locking here and there and is probably far from easy to do. | I use a Cyrus server and I do server-side splitting with Sieve. So Thanks, I'll check those out. I hope that splitting doesn't require anything special and could be done with procmail instead of that Sieve thingy. I'd rather avoid converting my 9k .procmailrc into another system. | getting new mail is real fast -- O(n) where n is the number of | subscribed groups. The splitting happens in the background. That's a | nice feature of the Gnus/nnimap combination. Indeed. | slow. Recently, I moved all articles from one 3500 message nnml group | to an 8000 message group, and that was real slow. Towards the end, yeah, and when you have 80000 articles instead of 8000, the real fun begins :) | of the last line is found. And writing new lines could happen by | appending to the existing file. Yes, that might be faster for large | overview files, but what's the size where it starts winning. Yes, that's what I thought too (and as far as I can see, it should start winning immediately or something is broken), but the fact that Gnus possibly removes some lines from those overview files or whatever (this is the part I didn't quite grok when reading the source) shoots down the idea of appending. | As to displaying large summary buffers, I find that I normally get by | with just displaying few messages. I switched from total-expire to So do I, normally, but there are few folders that I don't touch for a long time and then read all accumulated messages. This would be fine (it wouldn't hit me often) if I didn't peek into those folders for something important every now and then. | Rather than displaying thousands of messages to search for an old one, | I use nnir to search for it. (Should use nnir much more often, | though.) Hmm, I'll have to check that out too. I assume it handles full-text regexp searches, yes? -- Hannu