Re: nnimap 0.123 and pgnus 0.95

[Simon Josefsson <jas@pdc.kth.se>]

Jake Colman <colman@ppllc.com> writes:

> New issue:  processing of an nnimap group seems to be MUCH slower than
> before.  I upgraded from nnimap 0.90 to nnimap 0.123 -- a rather big jump.
> Has something changed in how you do your processing that would explain why it 
> is so much slower?

Very much has changed in this regard since then, but I think it's
supposed to be faster.

> I can understand that it would be slow if I was fetching ALL the
> headers for a large group.  But if I only have a few unread
> messages, shouldn't the fetch be quick regardless of how many read
> messages are already in the group?

Yes, they should be fast.

What is the value of `gnus-fetch-old-headers'?  I think older nnimap
versions didn't support that variable, but more recent do, and they
slow down things quite substantially.

What server are you using?  Nnimap has been changed from a simple
fetch of the RFC822 header into a more complex fetch. This is what
most clients do though, so I don't think to extra complexity can
explain your slowdown.

The article set calculation functions in Gnus are slow -- entering a
group where the UID range go from 10000000 to 40000000 with lots of
holes are likely to be unusably slow. Fortunely most servers seem to
keep the UIDs at a reasonable level.

You could also try profiling gnus/nnimap to see which functions takes
most time. Try this

<start gnus>
M-x untrace-all
M-x elp-instrument-package RET gnus RET
M-x elp-instrument-package RET imap RET
M-x elp-instrument-package RET nnimap 
<enter a group>
M-x elp-report

and mail us the output of the last command, it should provide enough
details to figure this out.

/Simon