nnimap issues

nnimap issues

[Simon Josefsson]

Hi!  I just downloaded the latest Gnus and it found the new nnimap stuff
(thanks for working on that!) and I noticed some issues:

1) Getting new mail is really really slow!  Looking at *imap-log*
explains why, there are tons of commands like this:

...
09:27:32 1706 EXAMINE "INBOX.grisslan"
09:27:32 1707 UID FETCH 1:* FLAGS
09:27:32 1708 EXAMINE "INBOX.mail-bounce"
09:27:32 1709 UID FETCH 1935:* FLAGS
09:27:32 1710 EXAMINE "INBOX.spamassassin"
09:27:32 1711 UID FETCH 180267:* FLAGS
09:27:32 1712 EXAMINE "INBOX.2009"
09:27:32 1713 UID FETCH 30541:* FLAGS
09:27:32 1714 EXAMINE "INBOX.sent-2009"
09:27:32 1715 UID FETCH 1763:* FLAGS
...

The 'UID FETCH 1:*' command is an O(n) operation (both in terms of
computation on client and server side but also on bandwidth) on the size
of the mailbox, and for large mailboxes this becomes really painful.  It
can results in MB's of data being pushed every time I press 'g'.

The old nnimap used the STATUS command to look for new mail instead.
There are controversies over whether this is a good idea or not, but
older IMAP RFCs support it and as far as I know, it is the fastest and
most reliable way to check for new mail.  Alternatively, doing a 'UID
FETCH 1,*' should be an O(1) operation.

Generally, why is it downloading all the flags on all messages over and
over again?  It should have all that cached anyway, except for possibly
new messages.

2) Nnimap no longer auto-discover that my server supports STARTTLS and
instead tried to use direct TLS, which obviously fails since my IMAP
server doesn't speak native TLS on the vanilla IMAP port.  I had to add
'nnimap-stream starttls' to my select method manually.  STARTTLS is the
recommended way to do TLS with IMAP so it would be nice to make this
work automatically.

3) When imap-log is non-nil, the *imap-log* buffer no longer contains
the output from the server, which makes debugging harder.

4) Nnimap mail splitting is not working any more.  All my e-mail sits in
INBOX and there is no filtering going on.  I don't see anything in
GNUS-NEWS about any change in this area, so it must be a bug. :-)

5) Selecting a IMAP group results in two SELECT operations?  From
*imap-log*:

09:34:53 2012 SELECT "INBOX.yxa-staff"
09:34:54 2013 SELECT "INBOX.yxa-staff"
09:34:54 2014 UID FETCH 6309:6315 (UID RFC822.SIZE BODYSTRUCTURE BODY.PEEK[HEADER.FIELDS (Subject From Date Message-Id References In-Reply-To Xref To Newsgroups)])
09:34:56 2015 UID FETCH 6309 BODY.PEEK[]

6) Deleting messages doesn't compress the article list, which for large
operations may result in too long lines:

09:35:05 2016 UID STORE 6309,6310,6311,6312,6313,6314,6315 +FLAGS.SILENT (\Deleted)
09:35:06 2017 UID EXPUNGE 6309,6310,6311,6312,6313,6314,6315
09:35:08 2018 UID STORE 6309:6315 +FLAGS.SILENT (\Seen)

Thanks,
/Simon

Re: nnimap issues

[Lars Magne Ingebrigtsen]

Simon Josefsson <simon@josefsson.org> writes:

> The 'UID FETCH 1:*' command is an O(n) operation (both in terms of
> computation on client and server side but also on bandwidth) on the size
> of the mailbox, and for large mailboxes this becomes really painful.  It
> can results in MB's of data being pushed every time I press 'g'.

It only requests the last 100 flags...

> The old nnimap used the STATUS command to look for new mail instead.
> There are controversies over whether this is a good idea or not, but
> older IMAP RFCs support it and as far as I know, it is the fastest and
> most reliable way to check for new mail.  Alternatively, doing a 'UID
> FETCH 1,*' should be an O(1) operation.
>
> Generally, why is it downloading all the flags on all messages over and
> over again?  It should have all that cached anyway, except for possibly
> new messages.

Before starting working on this, I was trolling the gnus-bug group, and
it seemed like the most constant complaint was "why is nnimap showing 30
unread messages while there's really only 2"?  I think the only way to
actually tell how many new messages have actually arrived when UIDNEXT
jumps from X to X+N is to do a UID FETCH X:*, isn't it?  (Please correct
me if I'm mistaken -- I'm not an IMAP expert).

So Gnus requests (- X 100):*, to just double-check whether any of the
most recent messages have changed their flags, too.

So the primary reason for the flag fetch isn't really to get the flags
(although that's a nice side-effect), but to find out how many new
articles there are in the mail box.

If there's a faster way to do this, I'd love to hear it.

(Oh, there's QRESYNC, which might speed stuff up, but I haven't
implemented that yet.)

> 2) Nnimap no longer auto-discover that my server supports STARTTLS and
> instead tried to use direct TLS, which obviously fails since my IMAP
> server doesn't speak native TLS on the vanilla IMAP port.  I had to add
> 'nnimap-stream starttls' to my select method manually.  STARTTLS is the
> recommended way to do TLS with IMAP so it would be nice to make this
> work automatically.

Yes, it should check the capabilites and auto-STARTTLS if it's
available, I guess?

> 3) When imap-log is non-nil, the *imap-log* buffer no longer contains
> the output from the server, which makes debugging harder.

I was planning on getting rid of the log buffer totally when it works
perfectly.  Any day now!  :-)

> 4) Nnimap mail splitting is not working any more.  All my e-mail sits in
> INBOX and there is no filtering going on.  I don't see anything in
> GNUS-NEWS about any change in this area, so it must be a bug. :-)

:-)  I've now added a mention, but it's mostly related to the new
nnimap-inbox variable, and using the standard nnmail-split-methods.

>
> 5) Selecting a IMAP group results in two SELECT operations?  From
> *imap-log*:
>
> 09:34:53 2012 SELECT "INBOX.yxa-staff"
> 09:34:54 2013 SELECT "INBOX.yxa-staff"

That looks like a bug.  I'll fix it...

> 6) Deleting messages doesn't compress the article list, which for large
> operations may result in too long lines:
>
> 09:35:05 2016 UID STORE 6309,6310,6311,6312,6313,6314,6315 +FLAGS.SILENT (\Deleted)
> 09:35:06 2017 UID EXPUNGE 6309,6310,6311,6312,6313,6314,6315
> 09:35:08 2018 UID STORE 6309:6315 +FLAGS.SILENT (\Seen)

Yup; fixed.

-- 
(domestic pets only, the antidote for overdose, milk.)
  larsi@gnus.org * Lars Magne Ingebrigtsen

Re: nnimap issues

[Lars Magne Ingebrigtsen]

Lars Magne Ingebrigtsen <larsi@gnus.org> writes:

> (Oh, there's QRESYNC, which might speed stuff up, but I haven't
> implemented that yet.)

I've now looked at what servers actually support QRESYNC.  Out of
Courier, Dovecot, Gmail, Zimbra and Cyrus (that's probably 95% market
coverage?), only Zimbra seems to support QRESYNC.  That's the test
servers, but it's possible that newer versions of some of these do
support it anyway.

But perhaps it's not worth implementing...

-- 
(domestic pets only, the antidote for overdose, milk.)
  larsi@gnus.org * Lars Magne Ingebrigtsen

Re: nnimap issues

[Steinar Bang]

>>>>> Lars Magne Ingebrigtsen <larsi@gnus.org>:

> Lars Magne Ingebrigtsen <larsi@gnus.org> writes:
>> (Oh, there's QRESYNC, which might speed stuff up, but I haven't
>> implemented that yet.)

> I've now looked at what servers actually support QRESYNC.  Out of
> Courier, Dovecot, Gmail, Zimbra and Cyrus (that's probably 95% market
> coverage?), only Zimbra seems to support QRESYNC.  That's the test
> servers, but it's possible that newer versions of some of these do
> support it anyway.

> But perhaps it's not worth implementing...

A quick google search seemed to indicate that dovecot 1.2 has QRESYNC,
and indeed, in my http://backports.debian.org 1.2.13 version of dovecot
on debian stable lists the following capabilities:

 ("IMAP4REV1" "LITERAL+" "SASL-IR" "LOGIN-REFERRALS" "ID" "ENABLE" "SORT" "SORT=DISPLAY" "THREAD=REFERENCES" "THREAD=REFS" "MULTIAPPEND" "UNSELECT" "IDLE" "CHILDREN" "NAMESPACE" "UIDPLUS" "LIST-EXTENDED" "I18NLEVEL=1" "CONDSTORE" "QRESYNC" "ESEARCH" "ESORT" "SEARCHRES" "WITHIN" "CONTEXT=SEARCH" "LIST-STATUS")

This means when the next debian stable slides into space, all debian
dovecots will start to support it (and start supporting UIDPLUS as
well...).

Re: nnimap issues

[Lars Magne Ingebrigtsen]

Steinar Bang <sb@dod.no> writes:

> This means when the next debian stable slides into space, all debian
> dovecots will start to support it (and start supporting UIDPLUS as
> well...).

Oh, OK, that means that it's probably worth supporting.

-- 
(domestic pets only, the antidote for overdose, milk.)
  larsi@gnus.org * Lars Magne Ingebrigtsen

Re: nnimap issues

[Daniel Pittman]

Lars Magne Ingebrigtsen <larsi@gnus.org> writes:
> Steinar Bang <sb@dod.no> writes:
>
>> This means when the next debian stable slides into space, all debian
>> dovecots will start to support it (and start supporting UIDPLUS as
>> well...).
>
> Oh, OK, that means that it's probably worth supporting.

IIRC, some of the active commercial developers of Cyrus IMAP are also looking
at including QRESYNC support for their own benefit.

        Daniel
-- 
✣ Daniel Pittman            ✉ daniel@rimspace.net            ☎ +61 401 155 707
               ♽ made with 100 percent post-consumer electrons

Re: nnimap issues

[Lars Magne Ingebrigtsen]

Lars Magne Ingebrigtsen <larsi@gnus.org> writes:

> Yes, it should check the capabilites and auto-STARTTLS if it's
> available, I guess?

Looking at this, we have to decide whether to start doing STARTTLS
before we get to the server -- we have to open the connection with
`starttls-open-stream', which requires an external program (or the
internal support Ted is working on), and can't just start with a simple
network connection and then switch if it turns out that the server
really supports STARTTLS.  Unfortunately.

I think.

-- 
(domestic pets only, the antidote for overdose, milk.)
  larsi@gnus.org * Lars Magne Ingebrigtsen

Re: nnimap issues

[Simon Josefsson]

Lars Magne Ingebrigtsen <larsi@gnus.org> writes:

> Lars Magne Ingebrigtsen <larsi@gnus.org> writes:
>
>> Yes, it should check the capabilites and auto-STARTTLS if it's
>> available, I guess?
>
> Looking at this, we have to decide whether to start doing STARTTLS
> before we get to the server -- we have to open the connection with
> `starttls-open-stream', which requires an external program (or the
> internal support Ted is working on), and can't just start with a simple
> network connection and then switch if it turns out that the server
> really supports STARTTLS.  Unfortunately.
>
> I think.

The old code opened a native elisp network connection, and upon noticing
the STARTTLS capability, re-opened the connection using starttls.el and
then upgraded that connection.  This was actually all done by imap.el,
and nnimap.el was not involved at all -- the only necessary thing is
that nnimap let imap.el auto-detect the stream to use by not providing a
imap-stream unless specified by the user.  See old code in imap-open:

...
    (message "imap: Connecting to %s..." imap-server)
    (if (null (let ((imap-stream (or imap-stream imap-default-stream)))
		(imap-open-1 buffer)))
	(progn
	  (message "imap: Connecting to %s...failed" imap-server)
	  nil)
      (when (null imap-stream)
	;; Need to choose stream.
	(let ((streams imap-streams))
	  (while (setq stream (pop streams))
	    ;; OK to use this stream?
	    (when (funcall (nth 1 (assq stream imap-stream-alist)) buffer)
	      ;; Stream changed?
	      (if (not (eq imap-default-stream stream))
		  (with-current-buffer (get-buffer-create
					(generate-new-buffer-name " *temp*"))
		    (mapc 'make-local-variable imap-local-variables)
		    (imap-disable-multibyte)
		    (buffer-disable-undo)
		    (setq imap-server (or server imap-server))
		    (setq imap-port (or port imap-port))
		    (setq imap-auth (or auth imap-auth))
		    (message "imap: Reconnecting with stream `%s'..." stream)
...

/Simon

Re: nnimap issues

[Lars Magne Ingebrigtsen]

Simon Josefsson <simon@josefsson.org> writes:

> The old code opened a native elisp network connection, and upon noticing
> the STARTTLS capability, re-opened the connection using starttls.el and
> then upgraded that connection.

Oh, right.  And with the new built-in gnutls support in Emacs 24, we
won't even have to drop the connection and reconnect -- we can just run
gnutls-boot (etc) on the socket after sending STARTTLS to the server.

But I'll implement it the way you did for Emacsen that doesn't have
gnutls-boot.

-- 
(domestic pets only, the antidote for overdose, milk.)
  larsi@gnus.org * Lars Magne Ingebrigtsen

Re: nnimap issues

[Simon Josefsson]

Lars Magne Ingebrigtsen <larsi@gnus.org> writes:

> Simon Josefsson <simon@josefsson.org> writes:
>
>> The 'UID FETCH 1:*' command is an O(n) operation (both in terms of
>> computation on client and server side but also on bandwidth) on the size
>> of the mailbox, and for large mailboxes this becomes really painful.  It
>> can results in MB's of data being pushed every time I press 'g'.
>
> It only requests the last 100 flags...

Then I wonder if it is the EXAMINE or the UID FETCH that is taken time,
compared to the old approach of using STATUS.

>> The old nnimap used the STATUS command to look for new mail instead.
>> There are controversies over whether this is a good idea or not, but
>> older IMAP RFCs support it and as far as I know, it is the fastest and
>> most reliable way to check for new mail.  Alternatively, doing a 'UID
>> FETCH 1,*' should be an O(1) operation.
>>
>> Generally, why is it downloading all the flags on all messages over and
>> over again?  It should have all that cached anyway, except for possibly
>> new messages.
>
> Before starting working on this, I was trolling the gnus-bug group, and
> it seemed like the most constant complaint was "why is nnimap showing 30
> unread messages while there's really only 2"?

As I recall, this isn't specific to nnimap, and happens for all backends
if there are holes in the article range.

> I think the only way to actually tell how many new messages have
> actually arrived when UIDNEXT jumps from X to X+N is to do a UID FETCH
> X:*, isn't it?  (Please correct me if I'm mistaken -- I'm not an IMAP
> expert).

Yes, I suspect so.

But does it have to EXAMINE+FETCH all groups unconditionally?  I think
it does that, right?  It could use the old approach with STATUS to
quickly see what mailboxes have changed at all, and then for those
(hopefully few) mailboxes that have changed, do the EXAMINE+FETCH dance.

Ah.  I think I got it: the old code sent the STATUS in parallel, like this:

1554 STATUS "INBOX.sent-2010" (UIDVALIDITY UIDNEXT UNSEEN)
1555 STATUS "INBOX.sent-2009" (UIDVALIDITY UIDNEXT UNSEEN)
1556 STATUS "INBOX.fossgrupp" (UIDVALIDITY UIDNEXT UNSEEN)
1557 STATUS "INBOX.apel-en" (UIDVALIDITY UIDNEXT UNSEEN)

and then waits for all the replies.  The new code iterates through all
groups and does EXAMINE+FETCH on each of them.

What is biting now may be all the round trips.  The roundtrips with the
new code is O(2*N) in number of mailboxes, whereas the old was O(1+2*M)
where M is the number of changed mailboxes (which is typically << N).

> So Gnus requests (- X 100):*, to just double-check whether any of the
> most recent messages have changed their flags, too.

I see, that seems like a nice thing.

> So the primary reason for the flag fetch isn't really to get the flags
> (although that's a nice side-effect), but to find out how many new
> articles there are in the mail box.
>
> If there's a faster way to do this, I'd love to hear it.

I propose to do:

1) Parallel STATUS like the old code to discover which groups have been
changed at all.

2) For those groups that have changed, do the EXAMINE+FETCH dance.

> (Oh, there's QRESYNC, which might speed stuff up, but I haven't
> implemented that yet.)

Could be useful...

>> 3) When imap-log is non-nil, the *imap-log* buffer no longer contains
>> the output from the server, which makes debugging harder.
>
> I was planning on getting rid of the log buffer totally when it works
> perfectly.  Any day now!  :-)

Oh no, it has saved my day many times.  Other mail clients, like Claws,
has a IMAP network inspection tool.  It would be a shame to see lose
this feature in Gnus..

>> 4) Nnimap mail splitting is not working any more.  All my e-mail sits in
>> INBOX and there is no filtering going on.  I don't see anything in
>> GNUS-NEWS about any change in this area, so it must be a bug. :-)
>
> :-)  I've now added a mention, but it's mostly related to the new
> nnimap-inbox variable, and using the standard nnmail-split-methods.

I'll take a look.

> Yup; fixed.

That idiom brings back memories.  Glad to have you back working on Gnus,
Lars!

/Simon

Re: nnimap issues

[Lars Magne Ingebrigtsen]

Simon Josefsson <simon@josefsson.org> writes:

> Then I wonder if it is the EXAMINE or the UID FETCH that is taken time,
> compared to the old approach of using STATUS.

On some servers the EXAMINE itself is slow, while on others it's fast.

> As I recall, this isn't specific to nnimap, and happens for all backends
> if there are holes in the article range.

Yes.  IMAP is unique, though, in that some servers have very sparse
article numbers, and that people read/delete messages from different
user agents routinely, and expect this to be reflected in all the user
agents... 

> But does it have to EXAMINE+FETCH all groups unconditionally?  I think
> it does that, right?  It could use the old approach with STATUS to
> quickly see what mailboxes have changed at all, and then for those
> (hopefully few) mailboxes that have changed, do the EXAMINE+FETCH dance.

But the problem is that STATUS will only say whether you've gotten a new
message, not whether you've read/deleted some of the messages via a
different user agent...

> Ah.  I think I got it: the old code sent the STATUS in parallel, like this:
>
> 1554 STATUS "INBOX.sent-2010" (UIDVALIDITY UIDNEXT UNSEEN)
> 1555 STATUS "INBOX.sent-2009" (UIDVALIDITY UIDNEXT UNSEEN)
> 1556 STATUS "INBOX.fossgrupp" (UIDVALIDITY UIDNEXT UNSEEN)
> 1557 STATUS "INBOX.apel-en" (UIDVALIDITY UIDNEXT UNSEEN)
>
> and then waits for all the replies.  The new code iterates through all
> groups and does EXAMINE+FETCH on each of them.
>
> What is biting now may be all the round trips.

No, they're still being streamed, like the old code.  nnimap now issues
a bunch of EXAMINE+FETCH commands, and then waits for the last response
to trickle in.  (Well, it usually doesn't wait, because this is now
issued early in the `g' cycle, so if you have other servers (like NNTP
or whatever), it'll issue the nnimap stuff first, then wait for the NNTP
stuff, and then look whether the IMAP stuff has arrived...)

However, it would make sense to allow the user to twiddle this.  If the
user only reads the IMAP groups from a single Gnus instance, then STATUS
would be fine.  Is that very common, though?

> 1) Parallel STATUS like the old code to discover which groups have been
> changed at all.
>
> 2) For those groups that have changed, do the EXAMINE+FETCH dance.

That would be possible, but then it'd have to wait for the STATUS
responses to arrive before doing any EXAMINE+FETCH stuff, which doubles
the round trips...

> That idiom brings back memories.  Glad to have you back working on Gnus,
> Lars!

It's fun to be back.  :-)

-- 
(domestic pets only, the antidote for overdose, milk.)
  larsi@gnus.org * Lars Magne Ingebrigtsen

Re: nnimap issues

[Steinar Bang]

>>>>> Lars Magne Ingebrigtsen <larsi@gnus.org>:

> However, it would make sense to allow the user to twiddle this.  If
> the user only reads the IMAP groups from a single Gnus instance, then
> STATUS would be fine.  Is that very common, though?

I don't know.  FWIW I routinely use three different gnusen: work, home
desktop machine, and home netbook.

But I have no idea how typical that is.

Re: nnimap issues

[Julien Danjou]

[-- Attachment #1: Type: text/plain, Size: 341 bytes --]

On Mon, Sep 27 2010, Steinar Bang wrote:

> I don't know.  FWIW I routinely use three different gnusen: work, home
> desktop machine, and home netbook.
>
> But I have no idea how typical that is.

With IMAP, I think it's really typical. Same setup here.

-- 
Julien Danjou
// ᐰ <julien@danjou.info>   http://julien.danjou.info

[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]

Re: nnimap issues

[Frank Schmitt]

Julien Danjou <julien@danjou.info> writes:

> On Mon, Sep 27 2010, Steinar Bang wrote:
>
>> I don't know.  FWIW I routinely use three different gnusen: work, home
>> desktop machine, and home netbook.
>>
>> But I have no idea how typical that is.
>
> With IMAP, I think it's really typical. Same setup here.

Make this five for me: 4 Gnusea (Home desktop, home netbook, work workstation,
work Laptop) and the (terribly crappy) Symbian client on my mobile.

-- 
Have you ever considered how much text can fit in eighty columns?  Given that a
signature typically contains up to four lines of text, this space allows you to
attach a tremendous amount of valuable information to your messages.  Seize the
opportunity and don't waste your signature on bullshit that nobody cares about.

Re: nnimap issues

[Steinar Bang]

>>>>> Simon Josefsson <simon@josefsson.org>:

> Hi!  I just downloaded the latest Gnus and it found the new nnimap stuff
> (thanks for working on that!) and I noticed some issues:

> 1) Getting new mail is really really slow!

Hm... I was wondering about that statement.  For me `g' appears a lot
faster than it used to...?

Entering groups may, or may not, be slower.  I can't tell.

But `g' do feel a lot snappier.

I still have the pre-nnimap version of gnus around.  Is there a way to
objectively time the `g'? (Ie. using elisp, not manual use of wall
clock...) 

Re: nnimap issues

[David Engster]

Steinar Bang writes:
>>>>>> Simon Josefsson <simon@josefsson.org>:
>
>> Hi!  I just downloaded the latest Gnus and it found the new nnimap stuff
>> (thanks for working on that!) and I noticed some issues:
>
>> 1) Getting new mail is really really slow!
>
> Hm... I was wondering about that statement.  For me `g' appears a lot
> faster than it used to...?
>
> Entering groups may, or may not, be slower.  I can't tell.
>
> But `g' do feel a lot snappier.
>
> I still have the pre-nnimap version of gnus around.  Is there a way to
> objectively time the `g'? (Ie. using elisp, not manual use of wall
> clock...) 

I've used

(benchmark-run 50
  (gnus-group-get-new-news))

to run it 50 times. This will return (total-time number-of-GCs time-for-GCs).

-David

Re: nnimap issues

[Steinar Bang]

>>>>> David Engster <deng@randomsample.de>:

>> But `g' do feel a lot snappier.

>> I still have the pre-nnimap version of gnus around.  Is there a way to
>> objectively time the `g'? (Ie. using elisp, not manual use of wall
>> clock...) 

> I've used

> (benchmark-run 50
>   (gnus-group-get-new-news))

> to run it 50 times. This will return (total-time number-of-GCs time-for-GCs).

Here are my results, both done on emacs 22.3 on RHEL4, Intel(R) Xeon(TM)
CPU 3.00GHz: 

; New gnus
(benchmark-run 50
  (gnus-group-get-new-news))
(36.122966999999996 21 1.2593269999999976)

; old gnus
(benchmark-run 50
  (gnus-group-get-new-news))
(85.283236 67 3.129354)

So a bit more than twice the wall clock time.  This is with a single
IMAP server, and 3 agentized NNTP server, and one un-agentized NNTP
server.  No local mail folders.

The "old gnus" test was done on a freshly gnus in a freshly started
emacs, so that should perhaps favour it a bit wrt. GC...?  Still, it had
over three times the number of GCs run.

Re: nnimap issues

[Lars Magne Ingebrigtsen]

Steinar Bang <sb@dod.no> writes:

> ; New gnus
> (benchmark-run 50
>   (gnus-group-get-new-news))
> (36.122966999999996 21 1.2593269999999976)
>
> ; old gnus
> (benchmark-run 50
>   (gnus-group-get-new-news))
> (85.283236 67 3.129354)

Nice.

-- 
(domestic pets only, the antidote for overdose, milk.)
  larsi@gnus.org * Lars Magne Ingebrigtsen

Re: nnimap issues

[Steinar Bang]

>>>>> Steinar Bang <sb@dod.no>:

> Here are my results, both done on emacs 22.3 on RHEL4, Intel(R) Xeon(TM)
> CPU 3.00GHz: 

With a single IMAP server, and 3 agentized NNTP server, and one
un-agentized NNTP server.  No local mail folders.

> ; New gnus
> (benchmark-run 50
>   (gnus-group-get-new-news))
> (36.122966999999996 21 1.2593269999999976)

> ; old gnus
> (benchmark-run 50
>   (gnus-group-get-new-news))
> (85.283236 67 3.129354)

Same machine, on today's git pull (ie. with QRESYNC, against a dovecot
1.2.13 that supports QRESYNC):

(benchmark-run 50
  (gnus-group-get-new-news))
(29.2807 15 0.8442219999999994)

Some performance improvement wrt. wall clock time, 25% fewer GCs.

Re: nnimap issues

[Lars Magne Ingebrigtsen]

Steinar Bang <sb@dod.no> writes:

> Same machine, on today's git pull (ie. with QRESYNC, against a dovecot
> 1.2.13 that supports QRESYNC):
>
> (benchmark-run 50
>   (gnus-group-get-new-news))
> (29.2807 15 0.8442219999999994)
>
> Some performance improvement wrt. wall clock time, 25% fewer GCs.

Nice.

-- 
(domestic pets only, the antidote for overdose, milk.)
  larsi@gnus.org * Lars Magne Ingebrigtsen