197468 - Moz 1.3 message download speed from imap erratic - can be 10 times slower than Moz 1.1.

Status: VERIFIED DUPLICATE of bug 147285

(MailNews Core :: Networking: IMAP, defect)

Description

[John Gerth]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.3) Gecko/20030312

This problem was noted when Mozilla 1.3 installs occurred on March 13.
It happens on Windows 2000 and Windows XP but *not* on Linux or Mac OS 10.2
We reproduced it on several machines, all with latest Service Packa and
"Critical Updates" applied.

Users here now routinely get fairly large attachments usually zipped
archives of things like drivers. The attachments are downloaded from
the imap server and then unpacked.  This can be either via "Open"
using winzip or some users do "Save as...." and then later unpack them.
However, we now notice that the direct "Save as..." is taking 10 times
longer than using the "Open" dialogue -- even if the choice within "Open"
is to "Save this file to disk"

After observing this we took a mail with two attachments one of ~1.5MB
one of ~8 MB and experimented on various systems and versions of Mozilla.
The attachments uniformly download quickly under Mozilla 1.1 on all
plaforms and all degrade by a factor of 10 or more on 1.3 under Windows
but *not* Linux or Mac.  Checking further we see the slowdown back as
far as Mozilla 1.2.1.

Removing 1.3 and reinstalling 1.1 on the systems restore performance.

Reproducible: Always

Steps to Reproduce:
1. Create mail with large attachment ( 2MB ) and send it 
2. Use Mozilla to open the message
3. Open the attachment pane
4. Compare download time of "Save as" with "Open"

Actual Results:  
For an 8.3 MB attachment, "Open" downloads in 3 seconds on 100 Mb/s ethernet
whereas "Save As..." can take minutes. You can see the "Open" download
to the user's temp directory occurring as soon as the Open dialog box
is pooped up. If the "Save to disk" option is used under Open it just
moves the copy from the temp dir,

Expected Results:  
Roughly equivalent times since this is the same functionality

Searching bugzilla turned up similar symptoms in 180516 (uploading),
but that's marked FIXED VERIFIED and 182383 (POP download) which
is still listed as unconfirmed.

Looking at the Windows XP network meter in the Task Manager doesn't
show any strikingly weird behavior nor was there a spike in CPU.
Things just go slowwwwwwwwwwwwwly.

Comment 1

[jhamilton]

I think this may be related to issues I'm having with Mozilla 1.3 on Windows 98.
Only difference is on 98 both "Open" and "Save As" take forever, at least that
has been my experience on three Win98 machines I tested it on in my office.

I noticed extreme slowness in opening large attachments and noted this on bug
153030. I can also confirm that on Linux I had no problems with either "Save As"
or "Open" being too slow.

John Gerth, please see my comment # 8 on bug 153030. Does opening a new browser
window as described therein make your "Save As" finish downloading instantly as
I noticed on the "Open" operation?

This bug is crippling the deployment of Mozilla in my organisation as we
regularly deal with large attachments on an IMAP server.

Comment 2

[John Gerth]

In response to comment #1, I did more extensive experiments this morning on Win2K.
I can report that opening a Navigator window during a slow download had
no visible effect on the speed. However, since Win9x systems don't have
true multitasking I could believe that the results could be very different there.

More to come on the other win2k results...

Comment 3

[John Gerth]

This morning I performed more controlled tests on Win2K with Moz 1.3 final.
For the tests, I created two emails
  1) one-line email with 10MB attachment
  2 [details] [diff] [review]) one-line emaiil with the first email as an attachment
I stored copies of the two emails in a new folders. one local and one
on the IMAP server. I also made the View setting to not display
attachments inline. The network is 100 Mb/s switched.

...local folder
Things go as you would expect. That is, they are constrained by
local disk speeds.  Since "Open" first copies the attachment to
your temp dir, you can camp out there and watch how fast it grows.

...IMAP folder
This continues to display erratic behavior although I have to modify
my original bug report in that "Open" can be just as slow as "Save as...".
This is probably a Good Thing in that it's likely they end up using
the same bits of code during the downloads. In the following, I report
what happens after you've absorbed the initial hit for downloading
the folder headers.

First, "Open" and "Save as..." are both extemely slow the first
time the attachment is processed. I consistently recorded over
2 minutes for download.

However, once an attachment has been downloaded once it appears
to become cached and subsequent "Opens" or "Save as..." go
quickly (under 10 seconds) - (not that this is very realistic
since it's the first download which people care about). 

One has to be careful in doing the experiments because speed
will remain high across Mail sessions if you don't also end
other Mozilla components too (one might imagine that the
caching remains in effect).

It's clear that this has to do with attachment processing
because you can actually copy the entire message to a
local folder quickly.

Finally, none of this happens on Mozilla 1.1 so it's
something more recent.

Comment 4

[John Gerth]

Gack...one has to be really careful when doing experiments in
the possible presence of caching.  After submitting my comment,
it occured to me that I might not've closed everything down
before doing the simple copy to local folder test.

Indeed, I was wrong...that copy is just as slow as the
attachment processing (over 2 minutes, i..e less than 10 KB/s).

This means all that it takes to see the slowdown is to 
drag'n'drop a large message from an imap folder to 
a local folder.

Once again, however switching back to Moz 1.1, but otherwise
leaving everthing else the same is fast.

All of the above experiments done from Win2K SP3+ using imaps to
a RedHat 8.0 server running UW imap (rpm is imap-2001a-11) over
100 MB/s switched ethernet.

So I'm going to try an change the problem statement
since the problem is not specific to  attachments.

Comment 5

[John Gerth]

*** This bug has been marked as a duplicate of 147285 ***

Comment 6

[Stephen Donner [:stephend] Not actively reading bugmail]

Verified dup