From: "Bjørn Mork" <bmork@dod.no>
Subject: Re: Slow nnimap expiry with expiry-target
Date: Mon, 06 Oct 2003 14:11:00 +0200 [thread overview]
Message-ID: <hv4qympnvv.fsf@rasputin.ws.nextra.no> (raw)
In-Reply-To: <iluy8wfmtxv.fsf@latte.josefsson.org>
Simon Josefsson <jas@extundo.com> writes:
> 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.
Don't think so. The problem seems to be in nnimap-expiry-target,
which include a
(dolist (art arts)
(nnimap-request-article art group server (current-buffer))
...
)
where arts is a list of messages to expire.
This is necessary if the target is a function or another backend, but
could be optimized away when the target is a folder on the same imap
server. How about something like this (which is already there in
nnimap.el but in the wrong place):
(defun nnimap-expiry-target (arts group server)
(unless (eq nnmail-expiry-target 'delete)
(if (and (not (functionp nnmail-expiry-target))
(gnus-server-equal (gnus-group-method nnmail-expiry-target)
(gnus-server-to-method
(format "nnimap:%s" server))))
;; moving article within same server, speed it up...
(and (nnimap-possibly-change-group group)
(imap-message-copy (imap-range-to-message-set arts)
(gnus-group-short-name nnmail-expiry-target)
'dontcreate nil nnimap-server-buffer))
(with-temp-buffer
(dolist (art arts)
(nnimap-request-article art group server (current-buffer))
;; hints for optimization in `nnimap-request-accept-article'
(let ((nnimap-current-move-article art)
(nnimap-current-move-group group)
(nnimap-current-move-server server))
(nnmail-expiry-target-group nnmail-expiry-target group)))))
;; It is not clear if `nnmail-expiry-target' somehow cause the
;; current group to be changed or not, so we make sure here.
(nnimap-possibly-change-group group server)))
> Fixing it would be nice. Too bad I keep buying faster machines,
> otherwise I probably would be inclined to work on it.
Hey, no problem. I can donate a 486 if you pay the postage :-)
Bjørn
--
So, trees are malignant?
next prev parent reply other threads:[~2003-10-06 12:11 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2003-09-23 12:34 Bjørn Mork
2003-09-23 14:59 ` Simon Josefsson
2003-09-23 17:37 ` Zack Weinberg
2003-09-23 18:11 ` Simon Josefsson
2003-09-23 19:41 ` Zack Weinberg
2003-09-23 19:56 ` Simon Josefsson
2003-09-23 19:59 ` Simon Josefsson
2003-09-23 20:41 ` Jochen Küpper
2003-09-23 20:56 ` Simon Josefsson
2003-09-24 10:42 ` Ted Zlatanov
2003-09-25 14:40 ` Reiner Steib
2003-09-25 17:54 ` Simon Josefsson
2003-09-26 2:57 ` Jesper Harder
2003-10-04 22:10 ` Adding "move" operation to Gnus backends (Was: Slow nnimap...) Steinar Bang
2003-10-10 3:05 ` Adding "move" operation to Gnus backends Jesper Harder
2003-10-06 12:11 ` Bjørn Mork [this message]
2003-10-06 17:58 ` Slow nnimap expiry with expiry-target Simon Josefsson
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=hv4qympnvv.fsf@rasputin.ws.nextra.no \
--to=bmork@dod.no \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).