214245 - Downloading message bodies in folders for offline viewing from IMAP server (IMAP4rev1 v12.264 on Linux) is very slow. Seen in all Mozilla and Thunderbird versions since Mozilla 1.1

Status: RESOLVED FIXED

(SeaMonkey :: MailNews: Backend, defect)

Description

[jack-moz]

User-Agent:       Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; .NET CLR 1.0.3705; .NET CLR 1.1.4322)
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624

If I perform a fresh install of Mozilla 1.4, configure IMAP, select my folders 
for offline viewing and perform a sync, the message bodies come in at a rate 
of 10-20 every few seconds.

For Mozilla versions up and including to 1.1 the performance is about 10 times 
this rate.  I have about 10000 messages in the folder I'm trying to sync.

I'm talking to an IMAP server on my LAN running WU IMAP4rev1 on Linux. 

Reproducible: Always

Steps to Reproduce:
1. Select folders (or inbox) with many messages for offline syncing from WU 
IMAP4 server
2. Sync
3. Compare to the time it took Mozilla 1.1 to do this

Actual Results:  
It takes much longer in Moz 1.4 than in 1.0 and 1.1

Expected Results:  
It should be fast.

I've seen this since Mozilla 1.2 (I downgraded to 1.1 because of this issue).  
I just tried the new Thunderbird release and it suffers from the same problem.

Comment 1

[David :Bienvenu]

try a 1.5 build - I believe I've fixed this.

Comment 2

[jack-moz]

I just tried this in last night's 1.5b:
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.5b) Gecko/20030729

The performace seems to be about the same as 1.4 - still very slow.  

According to the XP network performance monitor, 1.5b uses about 142KB/second 
inbound traffic when downloading my inbox from my server over 100Mbps LAN.

I reinstalled Mozilla 1.1 and downloading the same inbox uses about 3MB/second 
of inbound bandwidth.  The messages come in at about 10-20 times the rate that 
they do in 1.4/1.5b.

Comment 3

[David :Bienvenu]

cc'ing Darin. I originally thought the slowdown was because of some disk
flushing problem that caused the hard drive to churn when downloading messages,
but that's been fixed. I wonder if the slowdown has to do with necko changes in
1.2? It's hard for me to test this since I don't have a high speed connection.

Comment 4

[David :Bienvenu]

Attachment: possible fix

this patch makes it so we don't keep opening and closing the offline store, and
we don't commit the db for every message. That should help. I'm going to do
some performance tests to see.

Comment 5

[David :Bienvenu]

Attachment: possible fix, v2

same as previous patch except for a one line change/fix. This patch also
removes an unused method,  NotifyStoreClosedAllHeaders. I don't see much of a
speedup with this patch, but I don't know how fast my imap server is.

Comment 6

[David :Bienvenu]

you can try tomorrow's 1.5b daily build and see if it's faster - it should be
somewhat faster but I don't think it's 10-20 times faster than 1.4. If you could
let me know, I'd appreciate it.

Comment 7

[jack-moz]

Sure, I'll let you know tomorrow.  Thanks.

Comment 8

[jack-moz]

I tried last night's build "Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; 
rv:1.5b) Gecko/20030807".  Reading the inbox from my local IMAP server uses 
about only 125KB/sec - slightly slower than the last 1.5 beta I tried.  
Sorry :-(

Comment 9

[Rob Janssen]

I don't think it has anything to do with optimizations in the code.
This bug is reported in several bugnumbers, and in another I have already
commented: while the system is (painfully slowly) retrieving messages, all the
involved resources (server cpu, lan, client cpu, disk) are sitting idle.

My hypothesis is that instead of properly waiting on the returned message from
the  IMAP server, the client just waits on a timer event and when it occurs also
sees the server data.  So it processes only a fixed amount of server data,
almost unrelated to the system and network performance.

Comment 10

[David :Bienvenu]

necko might not be handing off data to the imap thread fast enough to keep it
busy - I thought necko was unblocked, however. I'll see if we're hitting the
throttling code still.

Comment 11

[David :Bienvenu]

Attachment: proposed fix

This patch cuts the time in half for me. The first line increases the size of
the buffers that necko holds onto for the input stream (it may or may not
help). The second part of the fix is just to increase the size of the buffer we
use for buffering lines, before proxying them over to the ui thread. Those
proxied calls are very expensive because we cross a thread boundary, among
other things, and increasing the buffer size reduces the number of the calls. I
arbitrarily picked 16K - I don't think increasing it is going to help much in
my test case since very few of the messages in my test case are > 16K, and
there has to be at least one call per message. I'll try to see what else I can
do to speed this up.

Comment 12

[David :Bienvenu]

Comment on attachment 129027 [details] [diff] [review]
possible fix, v2

checked in.

Comment 13

[David :Bienvenu]

Comment on attachment 129392 [details] [diff] [review]
proposed fix

the other thing about this patch is that it will speed up display/download of
all large imap messages.

Comment 14

[David :Bienvenu]

Attachment: cut out another 2 xpidl calls

this patch removes two more xpidl calls, which reduced my test case time by
close to another 50% (so in total, I went from 3 minutes to 45 seconds)

Comment 15

[(not reading, please use [e-mail] instead)]

Comment on attachment 129395 [details] [diff] [review]
cut out another 2 xpidl calls

r/sr/a=sspitzer for 1.5 beta

Comment 16

[David :Bienvenu]

fix checked in this morning - please let me know if it's faster for you now with
today's build (or maybe tomorrow's build - I'm not sure when the mozilla nightly
build is made). I'm still not seeing a 10x improvement but I am seeing a 4x
improvement for my test case and imap seems zippier in general.

Comment 17

[jack-moz]

I downloaded last night's nightly.  I'm seeing between 100KB/sec and 1MB/sec 
download network utilization.  Definitely much speedier - although not as fast 
as 1.1 it's pretty good. I think it hits the 1MB/sec when it'd downloading a 
single large email.

Comment 18

[David :Bienvenu]

great, thx, I can look into seeing what other idl calls we make, and if some of
them can be async instead of sync...

Comment 19

[David :Bienvenu]

I also changed IMAP to use blocking reads, which should make it twice as fast or so.