Re: nnimap slowness

[David Abrahams <dave@boost-consulting.com>]

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

Simon Josefsson <jas@extundo.com> writes:

> David Abrahams <dave@boost-consulting.com> writes:
>
>>>> When I look at the status line and see
>>>>
>>>>           imap read: 774K
>>>>
>>>> with the numbers spinning upwards at a rate of only about 15K per
>>>> second I grow highly doubtful that it's doing anything other than
>>>> reading data from my IMAP server.
>>>
>>> Hm, yes, this sounds as if it is the downloading that takes time.  Hm,
>>> maybe it is due to subprocesses in emacs under Windows.  Please try
>>> profiling the imap and nnimap packages to see where it is spending the
>>> time.  Maybe the gnus package too, so that the total time is available
>>> too (display probably still takes some non-negligible time).
>>
>> Here's the result for a `M-G' which is not retrieving any messages at
>> all, since none were sent (but still does the slow "imap read: ..."
>> dance up to about 24K).  If you want more data, I'll send myself
>> something big and profile that.
>
> For small data, the cause is much more likely to be server slowness or
> network latency, so please send try sending a 5MB attachment or
> something.

OK, here:


[-- Attachment #2: profile.zip --]
[-- Type: application/zip, Size: 4951 bytes --]

[-- Attachment #3: Type: text/plain, Size: 518 bytes --]


But I still think the fact that I get the "imap read: ..." dance
counting up to 27K *twice* when I do `M-G' and receive no messages is
highly suspicious.

> To find out what causes slowness for small data, you must tcpdump or
> ethereal the stream to see which side is delaying the transfer, or if
> it is the network that has high latency.  ELP data isn't that useful
> in this case.

Maybe I'll try that stuff later today if I can figure it out, thanks.

-- 
Dave Abrahams
Boost Consulting
www.boost-consulting.com