nnimap slow for message copy

nnimap slow for message copy

[Nicolas Kowalski]

Hello.

I have noticed some time ago that Pine is really faster at
moving/copying mail from an IMAP folder to another, when both folders
are on the same server. I also noticed that Gnus is really slow when
performing the same action.

The following *imap-log* shows what happens when I do a copy 'B c'
from one nnimap group to another, on the same server. The [...]
contains the message. It seems lime Gnus never uses the IMAP COPY
command. Is not there an optimization to do ?


214 UID FETCH 1247 BODY.PEEK[]
* 15 FETCH (UID 1247 BODY[] {3261}

[...]

214 OK UID FETCH completed
215 EXAMINE "mail.verimag"
* 19 EXISTS
* 0 RECENT
* OK [UIDVALIDITY 1019817492] UID validity status
* OK [UIDNEXT 1252] Predicted next UID
* FLAGS (gnus-expire \Answered \Flagged \Deleted \Draft \Seen)
* OK [PERMANENTFLAGS ()] Permanent flags
215 OK [READ-ONLY] EXAMINE completed
216 CLOSE
216 OK CLOSE completed
217 APPEND "mail.misc" {3261}

[...]

217 OK APPEND completed
218 EXAMINE "mail.misc"
* 15 EXISTS
* 1 RECENT
* OK [UIDVALIDITY 1019818304] UID validity status
* OK [UIDNEXT 18] Predicted next UID
* FLAGS (\Answered \Flagged \Deleted \Draft \Seen)
* OK [PERMANENTFLAGS ()] Permanent flags
* OK [UNSEEN 15] first unseen message in /var/imap/kowalski/mail.misc
218 OK [READ-ONLY] EXAMINE completed
219 UID FETCH * UID
* 15 FETCH (UID 17)
219 OK UID FETCH completed
220 EXAMINE "mail.misc"
* 15 EXISTS
* 1 RECENT
* OK [UIDVALIDITY 1019818304] UID validity status
* OK [UIDNEXT 18] Predicted next UID
* FLAGS (\Answered \Flagged \Deleted \Draft \Seen)
* OK [PERMANENTFLAGS ()] Permanent flags
* OK [UNSEEN 15] first unseen message in /var/imap/kowalski/mail.misc
220 OK [READ-ONLY] EXAMINE completed
221 CLOSE
221 OK CLOSE completed

Re: nnimap slow for message copy

[Simon Josefsson]

On Fri, 26 Apr 2002, Nicolas Kowalski wrote:

> I have noticed some time ago that Pine is really faster at
> moving/copying mail from an IMAP folder to another, when both folders
> are on the same server. I also noticed that Gnus is really slow when
> performing the same action.
> 
> The following *imap-log* shows what happens when I do a copy 'B c'
> from one nnimap group to another, on the same server. The [...]
> contains the message. It seems lime Gnus never uses the IMAP COPY
> command. Is not there an optimization to do ?

Yup.  Do you want to do it? :-)

The problem is that the Gnus backend interface doesn't use COPY when 
copying something, I think, so it ends up using fetch+store.  Of course, 
the nnimap backend could detect this situation and use COPY instead. (As 
it does when moving messages, I think.)

Re: nnimap slow for message copy

[Jody Klymak]

Simon Josefsson <jas@extundo.com> writes:

> The problem is that the Gnus backend interface doesn't use COPY when 
> copying something, I think, so it ends up using fetch+store.  Of course, 
> the nnimap backend could detect this situation and use COPY instead. (As 
> it does when moving messages, I think.)

Hi Simon,

Moving is really slow for me too.

Cheers,  Jody

-- 
Jody M. Klymak               mailto:jklymak@coas.oregonstate.edu
College of Oceanic and Atmospheric Sciences
Oregon State University, Corvallis, OR, 97331  

Re: nnimap slow for message copy

[Nicolas Kowalski]

Simon Josefsson <jas@extundo.com> writes:

> The problem is that the Gnus backend interface doesn't use COPY when 
> copying something, I think, so it ends up using fetch+store.  Of course, 
> the nnimap backend could detect this situation and use COPY instead. (As 
> it does when moving messages, I think.)

Hm, reading nnimap.el (line 1294), I see :

(deffoo nnimap-request-accept-article (group &optional server last)
  (when (nnimap-possibly-change-server server)
    (let (uid)
      (if (setq uid
		(if (string= nnimap-current-server nnimap-current-move-server)
		  ;; moving article within same server, speed it up...
		    (and (nnimap-possibly-change-group
			  nnimap-current-move-group)
			 (imap-message-copy (number-to-string
					     nnimap-current-move-article)
					    group 'dontcreate nil
					    nnimap-server-buffer))


So the optimization already exists...I simply do not understand what
this function is supposed to do, nor how to use it with a
group-to-group copy.

Re: nnimap slow for message copy

[Simon Josefsson]

Nicolas Kowalski <Nicolas.Kowalski@imag.fr> writes:

> Simon Josefsson <jas@extundo.com> writes:
>
>> The problem is that the Gnus backend interface doesn't use COPY when 
>> copying something, I think, so it ends up using fetch+store.  Of course, 
>> the nnimap backend could detect this situation and use COPY instead. (As 
>> it does when moving messages, I think.)
>
> Hm, reading nnimap.el (line 1294), I see :
>
> (deffoo nnimap-request-accept-article (group &optional server last)
>   (when (nnimap-possibly-change-server server)
>     (let (uid)
>       (if (setq uid
> 		(if (string= nnimap-current-server nnimap-current-move-server)
> 		  ;; moving article within same server, speed it up...
> 		    (and (nnimap-possibly-change-group
> 			  nnimap-current-move-group)
> 			 (imap-message-copy (number-to-string
> 					     nnimap-current-move-article)
> 					    group 'dontcreate nil
> 					    nnimap-server-buffer))
>
>
> So the optimization already exists...

Yes, but only used when moving articles.  I guess the details could be
set when copying articles too?

> I simply do not understand what this function is supposed to do, nor
> how to use it with a group-to-group copy.

Look at `nnimap-request-move-article'.  Setting the same details from
`nnimap-request-article' could work.