From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.io/gmane.emacs.gnus.general/54022 Path: main.gmane.org!not-for-mail From: "Zack Weinberg" Newsgroups: gmane.emacs.gnus.general Subject: Re: Slow nnimap expiry with expiry-target Date: Tue, 23 Sep 2003 10:37:50 -0700 Sender: ding-owner@lists.math.uh.edu Message-ID: <87r827mmmp.fsf@codesourcery.com> References: NNTP-Posting-Host: deer.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable X-Trace: sea.gmane.org 1064338965 18498 80.91.224.253 (23 Sep 2003 17:42:45 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Tue, 23 Sep 2003 17:42:45 +0000 (UTC) Cc: ding@gnus.org Original-X-From: ding-owner+M2562@lists.math.uh.edu Tue Sep 23 19:42:43 2003 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 1A1rBT-0007MF-00 for ; Tue, 23 Sep 2003 19:42:43 +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 1A1rAC-00031Q-00; Tue, 23 Sep 2003 12:41:24 -0500 Original-Received: from justine.libertine.org ([66.139.78.221]) by malifon.math.uh.edu with esmtp (Exim 3.20 #1) id 1A1rA2-00030Y-00 for ding@lists.math.uh.edu; Tue, 23 Sep 2003 12:41:14 -0500 Original-Received: from mail.codesourcery.com (voldemort.codesourcery.com [65.73.237.138]) by justine.libertine.org (Postfix) with ESMTP id B4E823A009C for ; Tue, 23 Sep 2003 12:41:13 -0500 (CDT) Original-Received: (qmail 15688 invoked from network); 23 Sep 2003 17:34:19 -0000 Original-Received: from dsl092-218-083.sfo2.dsl.speakeasy.net (HELO taltos.codesourcery.com) (zack@66.92.218.83) by mail.codesourcery.com with DES-CBC3-SHA encrypted SMTP; 23 Sep 2003 17:34:19 -0000 Original-Received: by taltos.codesourcery.com (sSMTP sendmail emulation); Tue, 23 Sep 2003 10:37:50 -0700 Original-To: =?iso-8859-1?q?Bj=F8rn_Mork?= In-Reply-To: (Simon Josefsson's message of "Tue, 23 Sep 2003 16:59:56 +0200") User-Agent: Gnus/5.1002 (Gnus v5.10.2) Emacs/21.3 (gnu/linux) Precedence: bulk Xref: main.gmane.org gmane.emacs.gnus.general:54022 X-Report-Spam: http://spam.gmane.org/gmane.emacs.gnus.general:54022 Simon Josefsson writes: > Bj=F8rn Mork writes: > >> I'm using total-expire to archive old messages from some of my nnimap >> folders, using another nnimap folder as expiry-target. This is >> incredibly slow, often using several minutes to move just a few small >> messages from one folder to another on the same imap server. >> >> Turning on imap-log gave me an idea of why. Expiring 19 messages >> resulted in a 5 MB imap-log! Shouldn't this be just one search, one >> copy, one flag update and one expunge? How come it adds up to a 5 MB >> log? ... >> 1) fetching the messages from the server. I can't see any reason for >> this. We have the list of UIDs to move. We are using imap copy on >> the server. There is no need to download the messages. This is >> of course extra annoying when reading mail on a slow link and some >> message with a large attachment suddenly is up for expiration... > > I think the problem may be because the Gnus backend interface doesn't > include a 'move' command. It only has retrieve + append. Nnimap at > least optimize the append operation into copy, but it cannot optimize > away the retrieve. Consistent with this, I observe exactly the same behavior on user-requested move and delete operations (B m, B DEL). It's frustrating enough that I've given up using Gnus expiry and instead have a cron job that executes on the IMAP server and diddles the folders directly. >> I am sure there are reasons I can't see for some or all of these, but >> there must be *something* that can be done to speed up nnimap expiry. > > Fixing it would be nice. Too bad I keep buying faster machines, > otherwise I probably would be inclined to work on it. It's a slow-network issue more than a slow-machine issue. Case in point, I'm getting tons of Windows mail worms right now that average around 128K. Gnus downloads the entire thing when asked to move them to the spam folder; this takes a second or so over an 1.5MBps encrypted channel, which is annoying but not unusable. It would be worse over a modem. How much work would it be to add a 'move' operation to the Gnus backend interface? (I am not volunteering.) zw