Slow nnimap expiry with expiry-target

Slow nnimap expiry with expiry-target

[Bjørn Mork]

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?  

Well, what Gnus does:

Searching for messages to expire:
1397 UID SEARCH UID ... NOT SINCE 29-Aug-2003

Processing first message:
1398 UID FETCH 33156 BODY.PEEK[]
1399 SELECT "INBOX.lest"
1400 UID SEARCH UNSEEN UNDELETED
1401 UID SEARCH SEEN
1402 UID SEARCH FLAGGED
1403 UID SEARCH ANSWERED
1404 UID SEARCH RECENT
1405 FETCH 1,* UID
1406 SELECT "INBOX"
1407 UID COPY 33156 "INBOX.lest"
1408 EXAMINE "INBOX.lest"
1409 UID FETCH * UID
1410 SELECT "INBOX"
1411 SELECT "INBOX.lest"
1412 UID SEARCH UNSEEN UNDELETED
1413 UID SEARCH SEEN
1414 UID SEARCH FLAGGED
1415 UID SEARCH ANSWERED
1416 UID SEARCH RECENT
1417 FETCH 1,* UID
1418 UID STORE 1:5175 +FLAGS (\Seen)

Processing second message:
1419 SELECT "INBOX"
1420 UID FETCH 33158 BODY.PEEK[]
1421 SELECT "INBOX.lest"
1422 UID SEARCH UNSEEN UNDELETED
1423 UID SEARCH SEEN
etc like above for all 19 messages.

Deleting:
1815 SELECT "INBOX"
1816 UID STORE 33156,33158,33170,33173,33183,33188,33193,33198,33222,33237:33238,33244,33248,33367,33382,33385:33387,33399 +FLAGS (\Deleted)
1817 STATUS "INBOX" (unseen)
1818 EXPUNGE


The problems I can spot are

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...
2) repeatedly fetching all flags for all messages in the folder we are
   moving to.  If there is any point in this at all, there certainly
   can't be any point in repeating it 38 times to move 19 messages?
   Some of the returned lists of UIDs are very long (#\Seen is
   typically identical to #messages in the folder, #\Answered is also
   often a long list).  Flags are cached by Gnus, are they not?
   Anyway,
3) "UID STORE ... +FLAGS (\Seen)" results in as many lines of response
   from the imap server as there are messages in the folder.  And
   it seems totally unecessary.  According to RFC 2060 flags SHOULD be
   preserved in the copy.  And why repeat this for every moved message
   even if it should prove necessary?

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.
It's annoyingly slow as it is now.


Bjørn
-- 
It takes a white slimebag like you to say that a homosexual man ain't
got nothing in the world these days.

Re: Slow nnimap expiry with expiry-target

[Simon Josefsson]

Bjørn Mork <bmork@dod.no> 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?

Ouch.

> Well, what Gnus does:
>
> Searching for messages to expire:
> 1397 UID SEARCH UID ... NOT SINCE 29-Aug-2003
>
> Processing first message:
> 1398 UID FETCH 33156 BODY.PEEK[]
> 1399 SELECT "INBOX.lest"
> 1400 UID SEARCH UNSEEN UNDELETED
> 1401 UID SEARCH SEEN
> 1402 UID SEARCH FLAGGED
> 1403 UID SEARCH ANSWERED
> 1404 UID SEARCH RECENT
> 1405 FETCH 1,* UID
> 1406 SELECT "INBOX"
> 1407 UID COPY 33156 "INBOX.lest"
> 1408 EXAMINE "INBOX.lest"
> 1409 UID FETCH * UID
> 1410 SELECT "INBOX"
> 1411 SELECT "INBOX.lest"
> 1412 UID SEARCH UNSEEN UNDELETED
> 1413 UID SEARCH SEEN
> 1414 UID SEARCH FLAGGED
> 1415 UID SEARCH ANSWERED
> 1416 UID SEARCH RECENT
> 1417 FETCH 1,* UID
> 1418 UID STORE 1:5175 +FLAGS (\Seen)
>
> Processing second message:
> 1419 SELECT "INBOX"
> 1420 UID FETCH 33158 BODY.PEEK[]
> 1421 SELECT "INBOX.lest"
> 1422 UID SEARCH UNSEEN UNDELETED
> 1423 UID SEARCH SEEN
> etc like above for all 19 messages.
>
> Deleting:
> 1815 SELECT "INBOX"
> 1816 UID STORE 33156,33158,33170,33173,33183,33188,33193,33198,33222,33237:33238,33244,33248,33367,33382,33385:33387,33399 +FLAGS (\Deleted)
> 1817 STATUS "INBOX" (unseen)
> 1818 EXPUNGE
>
>
> The problems I can spot are
>
> 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.

> 2) repeatedly fetching all flags for all messages in the folder we are
>    moving to.  If there is any point in this at all, there certainly
>    can't be any point in repeating it 38 times to move 19 messages?
>    Some of the returned lists of UIDs are very long (#\Seen is
>    typically identical to #messages in the folder, #\Answered is also
>    often a long list).  Flags are cached by Gnus, are they not?

Yes.  Most likely the copying code is doing the equivalent of 'M-g' or
'RET' on a group.  I doubt this is needed, at least it is not needed
after each article.  But it is probably done at different API levels,
so may be tricky to optimize away without rewriting something.

> 3) "UID STORE ... +FLAGS (\Seen)" results in as many lines of response
>    from the imap server as there are messages in the folder.  And
>    it seems totally unecessary.  According to RFC 2060 flags SHOULD be
>    preserved in the copy.  And why repeat this for every moved message
>    even if it should prove necessary?

I think there are two problems here:

* Setting the article flags is done since Gnus doesn't have a 'move'
  command, only a retrieve + append.  So it doesn't know the COPY
  command preserved the flags.

* The 'UID STORE 1:5175 +FLAGS (\Seen)' command actually seems to be a
  bug, it should never send a command like that after copying one
  article.

> 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.

Re: Slow nnimap expiry with expiry-target

[Zack Weinberg]

Simon Josefsson <jas@extundo.com> writes:

> Bjørn Mork <bmork@dod.no> 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

Re: Slow nnimap expiry with expiry-target

[Simon Josefsson]

"Zack Weinberg" <zack@codesourcery.com> writes:

>>> 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.

Yup.  I'm behind a (twice) encrypted 128kbps and have noticed this as
well, but only when I read faster than the asynchronous prefetch.

> How much work would it be to add a 'move' operation to the Gnus
> backend interface?  (I am not volunteering.)

Not much work.  Making the move summary command actually use it would
be slightly harder, but not that difficult either.  Perhaps in Gnus
5.11?

Re: Slow nnimap expiry with expiry-target

[Zack Weinberg]

Simon Josefsson <jas@extundo.com> writes:

> "Zack Weinberg" <zack@codesourcery.com> writes:
>>
>> 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.
>
> Yup.  I'm behind a (twice) encrypted 128kbps and have noticed this as
> well, but only when I read faster than the asynchronous prefetch.

I didn't even know Gnus had asynchronous prefetch.  Is this another
spiffy agent feature?  (I have been unable to get the agent to do
anything useful, as far as I can tell.)

>> How much work would it be to add a 'move' operation to the Gnus
>> backend interface?  (I am not volunteering.)
>
> Not much work.  Making the move summary command actually use it would
> be slightly harder, but not that difficult either.  Perhaps in Gnus
> 5.11?

Sounds like a good plan.  Other improvements to the IMAP backend would
be nice in that timeframe, too (partial fetch!)

zw

Re: Slow nnimap expiry with expiry-target

[Simon Josefsson]

"Zack Weinberg" <zack@codesourcery.com> writes:

> Simon Josefsson <jas@extundo.com> writes:
>
>> "Zack Weinberg" <zack@codesourcery.com> writes:
>>>
>>> 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.
>>
>> Yup.  I'm behind a (twice) encrypted 128kbps and have noticed this as
>> well, but only when I read faster than the asynchronous prefetch.
>
> I didn't even know Gnus had asynchronous prefetch.  Is this another
> spiffy agent feature?  (I have been unable to get the agent to do
> anything useful, as far as I can tell.)

Nope, it is separate from the agent, although it might populate the
agent, I'm not sure.  Anyway, see
<info:Asynchronous+Article+Fetching>.

>>> How much work would it be to add a 'move' operation to the Gnus
>>> backend interface?  (I am not volunteering.)
>>
>> Not much work.  Making the move summary command actually use it would
>> be slightly harder, but not that difficult either.  Perhaps in Gnus
>> 5.11?
>
> Sounds like a good plan.  Other improvements to the IMAP backend would
> be nice in that timeframe, too (partial fetch!)

Yup.  I hope someone who has time to implement this is listening. :-)

Re: Slow nnimap expiry with expiry-target

[Simon Josefsson]

Simon Josefsson <jas@extundo.com> writes:

> <info:Asynchronous+Article+Fetching>.

Or <info:Gnus/Asynchronous+Article+Fetching> maybe?  What are people
using to generate info URLs?  I keep forgetting the info URL syntax,
and it seems like something that should be automated anyway.

Re: Slow nnimap expiry with expiry-target

[Jochen Küpper]

On Tue, 23 Sep 2003 21:59:35 +0200 Simon Josefsson wrote:

Simon> Or <info:Gnus/Asynchronous+Article+Fetching> maybe?  

(info "(gnus)Asynchronous Fetching")

Simon> What are people using to generate info URLs? 

Reiner Steib posted his solution a while ago, this is my copy of it:
,----
| ;;
| ;; The following functions to insert info-links into a buffer were originaly
| ;; posted on gnu.emacs.gnus by Reiner Steib, August 2003.
| ;; Message-ID: <v9smo83rof.fsf_-_=WZbs9ZYJ0ya4nSHvGpykACzlmkwuQ7VwhC4ANOJQIlc@public.gmane.org>
| ;;
| (defvar jk/info-goto-node-string "info" ; "Info-goto-node"
|   ;; Stefan Monnier suggested to use `info' instead of `Info-goto-node', but
|   ;; this doesn't work for XEmacs.  OTOH, Reiner says he submitted a patch for
|   ;; XEmacs, so "info" should be okay.
|   "Command string to insert with `jk/insert-current-info-node'")
| 
| (defun jk/current-info-node (&optional arg)
|   "Insert reference to current Info node in buffer.
| 
| If ARG is...
| - nil:	Insert `\(info \"\(file\)node\"\)'.
| - 4 (\\[universal-argument]):	Add a note about `C-x C-e', too.
| - 16 (2 \\[universal-argument]'s):	Insert `<info://file/node>'
| - the symbol `string':	Only return the string, don't insert.
| 
| In emacs-lisp-mode a custom link is inserted."
|   (interactive "p")
|   (let ((what
| 	 (cond
| 	  ((eq major-mode 'emacs-lisp-mode)
| 	   'lisp)
| 	  ((numberp arg)
| 	   (cond
| 	    ((= arg 4) 'gnus-url)
| 	    ((= arg (* 4 4)) 'info-press)
| 	    (t 'info)))
| 	  ((eq arg 'string)
| 	   'string)
| 	  (t 'info)))
| 	(buffer (buffer-name))
| 	(ret ""))
|     ;; The next lines are borrowed from Karl Pflaesterer's code in
|     ;; <m3eli7tgp0.fsf=I0+XGIwFrHi1NNnFew4Tsd10ftHNP/Qe@public.gmane.org>.
|     (set-buffer "*info*")
|     (let* ((node Info-current-node)
| 	   (nodeurl (jk/replace-in-string node " " "+"))
| 	   (file Info-current-file)
| 	   (fileurl (file-name-nondirectory file))
| 	   (fileurl (jk/replace-in-string fileurl "\\.gz$" ""))
| 	   (fileurl (jk/replace-in-string fileurl "\\.info$" "")))
|       (set-buffer buffer)
|       (setq ret
| 	    (cond
| 	     ((eq what 'lisp)
| 	      (beginning-of-line)
| 	      (insert ":link '(custom-manual \"(" fileurl ")" node "\")")
| 	      (lisp-indent-line)
| 	      (newline))
| 	     ((eq what 'gnus-url)
| 	      (concat "<info://" fileurl "/" nodeurl ">"))
| 	     (t ;; (or (eq what 'info) (eq what 'info-press))
| 	      (concat "(" jk/info-goto-node-string
| 		      " \"(" fileurl ")" node "\")"
| 		      (if (eq what 'info-press)
| 			  "; <== Press C-x C-e here!"
| 			"")))))
|       (if (or (eq what 'string) (eq what 'lisp))
| 	  ret
| 	(insert ret)))))
| 
| (defun jk/boxquote-info ()
|   "Boxquote current yank-buffer and put current info node in title"
|   (interactive)
|   (boxquote-yank)
|   (boxquote-title (jk/current-info-node 'string)))
`----




Greetings,
Jochen
-- 
Einigkeit und Recht und Freiheit                http://www.Jochen-Kuepper.de
    Liberté, Égalité, Fraternité                GnuPG key: CC1B0B4D
        Sex, drugs and rock-n-roll

Re: Slow nnimap expiry with expiry-target

[Simon Josefsson]

Jochen Küpper <jochen@jochen-kuepper.de> writes:

> Simon> What are people using to generate info URLs? 
>
> Reiner Steib posted his solution a while ago, this is my copy of it:

Ah, nice, thanks.

Re: Slow nnimap expiry with expiry-target

[Ted Zlatanov]

On Tue, 23 Sep 2003, jochen@jochen-kuepper.de wrote:

On Tue, 23 Sep 2003 21:59:35 +0200 Simon Josefsson wrote:
> 
> Simon> Or <info:Gnus/Asynchronous+Article+Fetching> maybe?  
> 
> (info "(gnus)Asynchronous Fetching")
> 
> Simon> What are people using to generate info URLs? 
> 
> Reiner Steib posted his solution a while ago, this is my copy of it:

This is very nice.  Is there any way to get tab completion as well
while in the Gnus message buffer, using the currently opened info
buffers?  I do this a lot, have the Gnus manual open to check a post
and then say "look at <blah>" in the post itself.  With some sort of
tab completion on a message-insert-info-node function, life would be
easier and inserting info references would be fun.

Ted

Re: Slow nnimap expiry with expiry-target

[Reiner Steib]

On Wed, Sep 24 2003, Ted Zlatanov wrote:

> On Tue, 23 Sep 2003, jochen@jochen-kuepper.de wrote:
>> On Tue, 23 Sep 2003 21:59:35 +0200 Simon Josefsson wrote:
>> Simon> Or <info:Gnus/Asynchronous+Article+Fetching> maybe?  

The "Gnus home-style style" is <info://Gnus/Asynchronous+Fetching>.

    ;; This is info (home-grown style) <info://foo/bar+baz>

Note that the node name doesn't need to be the same as the section
title.

>> (info "(gnus)Asynchronous Fetching")

... or the GMOME and KDE style, added by Jesper recently:

    ;; Info GNOME style <info:foo#bar_baz>
    ;; Info KDE style <info:(foo)bar baz>

>> Simon> What are people using to generate info URLs? 
>> 
>> Reiner Steib posted his solution a while ago, this is my copy of it:
>
> This is very nice.  

I also added the GNOME and KDE style to my function some weeks ago (on
a different machine), but apparently I didn't sync the file.  If it's
still on the other machine, I will post it here.

> Is there any way to get tab completion as well while in the Gnus
> message buffer, using the currently opened info buffers?  

Do you mean multiple (independent) info buffers?  IIRC there's a
variable to enable this, but I couldn't find it now.

> I do this a lot, have the Gnus manual open to check a post and then
> say "look at <blah>" in the post itself.  

Most of the time, I have to navigate to the node anyhow.  So this is
not very high priority for me.

> With some sort of tab completion on a message-insert-info-node
> function, life would be easier and inserting info references would
> be fun.

I guess one could use `Info-complete-menu-item' and friends.

Bye, Reiner.

P.S.: Ted, no need to Cc me -- I read this list.  And I would prefer
      not to receive Swen & Co. to my work address too (some thousands
      to $Reply-To is enough -- at least bogofilter has got sufficient
      training samples now :-)).
-- 
       ,,,
      (o o)
---ooO-(_)-Ooo--- PGP key available via WWW   http://rsteib.home.pages.de/

Re: Slow nnimap expiry with expiry-target

[Simon Josefsson]

Reiner Steib <4.uce.03.r.s@nurfuerspam.de> writes:

> On Wed, Sep 24 2003, Ted Zlatanov wrote:
>
>> On Tue, 23 Sep 2003, jochen@jochen-kuepper.de wrote:
>>> On Tue, 23 Sep 2003 21:59:35 +0200 Simon Josefsson wrote:
>>> Simon> Or <info:Gnus/Asynchronous+Article+Fetching> maybe?  
>
> The "Gnus home-style style" is <info://Gnus/Asynchronous+Fetching>.
>
>     ;; This is info (home-grown style) <info://foo/bar+baz>
>
> Note that the node name doesn't need to be the same as the section
> title.

I wonder if we, GNOME and KDE should use another URI name...

http://www.ietf.org/internet-drafts/draft-vandesompel-info-uri-00.txt

Re: Slow nnimap expiry with expiry-target

[Jesper Harder]

Simon Josefsson <jas@extundo.com> writes:

> I wonder if we, GNOME and KDE should use another URI name...
>
> http://www.ietf.org/internet-drafts/draft-vandesompel-info-uri-00.txt

I think they should pick another name which doesn't conflict with
current usage.

Hmm, I think I'll send a note to the bug-texinfo guys.

Adding "move" operation to Gnus backends (Was: Slow nnimap...)

[Steinar Bang]

>>>>> Simon Josefsson <jas@extundo.com>:

> "Zack Weinberg" <zack@codesourcery.com> writes:

>> Simon Josefsson <jas@extundo.com> writes:

>>> "Zack Weinberg" <zack@codesourcery.com> writes:

>>>> How much work would it be to add a 'move' operation to the Gnus
>>>> backend interface?  (I am not volunteering.)

>>> Not much work.  Making the move summary command actually use it
>>> would be slightly harder, but not that difficult either.  Perhaps
>>> in Gnus 5.11?

>> Sounds like a good plan.  Other improvements to the IMAP backend
>> would be nice in that timeframe, too (partial fetch!)

> Yup.  I hope someone who has time to implement this is listening. :-)

Is there a bug report system for Gnus?

Seems like this idea deserves some more permanent registration than
being hidden deep down in a thread on the ding mailing list.

Re: Adding "move" operation to Gnus backends

[Jesper Harder]

Steinar Bang <sb@dod.no> writes:

>>> Sounds like a good plan.  Other improvements to the IMAP backend
>>> would be nice in that timeframe, too (partial fetch!)
>
>> Yup.  I hope someone who has time to implement this is listening. :-)
>
> Is there a bug report system for Gnus?
>
> Seems like this idea deserves some more permanent registration than
> being hidden deep down in a thread on the ding mailing list.

Send a patch for the 'todo' file :-)

Re: Slow nnimap expiry with expiry-target

[Bjørn Mork]

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?  

Re: Slow nnimap expiry with expiry-target

[Simon Josefsson]

Bjørn Mork <bmork@dod.no> writes:

> 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):

Seems reasonable.  As I don't use expiring in nnimap, I cannot really
test this, so if people say it works, perhaps it could be added.

>> 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 :-)

As long as I have a faster machine, I wouldn't use a 486 anyway. :-)