Lag and momentary freeze adding large attachment in compose message



MailNews Core
17 years ago
9 years ago


(Reporter: Benjamin Mucci, Assigned: Jean-Francois Ducarroz)


({hang, perf})

hang, perf
Dependency tree / graph

Firefox Tracking Flags

(Not tracked)



(1 attachment)



17 years ago
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (Macintosh; U; PPC; en-US; rv:0.9.2) Gecko/20010629
BuildID:    2001062823

When I attache a large file (for exemple 15MB) a very long lag happens for about
4 minutes. A can move the cursor bug everything else freeze. I don't think it's
a network problem (I'm on a ethernet LAN) because I can do the exact same thing
in NS4.7 in less than 30 secs! It's probably the sequence "read file ->
assembling message -> write in sent folder" that isn't enough optimized... 

Reproducible: Always
Steps to Reproduce:
1. New message
2. Attache something *big* ex: 15mb
3. Press Send and wait...

Actual Results:  Freeze for 4 minutes...

Expected Results:  No Freeze and should be faster! (Less then 30 secs like NS4.7
at less)


17 years ago
Assignee: mscott → ducarroz
Component: Networking - SMTP → Composition
QA Contact: nbaca → sheelar

Comment 1

17 years ago


17 years ago
QA Contact: sheelar → esther

Comment 2

17 years ago
using branch build id: 2001070205 on mac. It took me about 4 minutes and 10 
seconds to send a 14MB attachment.  The application did not appear to freeze 
all the time. In between certain process while it was sending and copying to 
sent folder I could select other applications. But it took too long.  
I sent the same file using 4.7 with the same server and the whole process was 
done in 1 minute and 17 seconds.  
Ever confirmed: true

Comment 3

17 years ago
cc-ing related people. Sending process has slowed down in recent builds. As I
mentioned below for comparison same file attached and sent with 4.x took less
time than 6.x.  I don't think this has anything to do with server behavior. I am
not sure if any regressions have caused this in the recent build. I will try
this on both win98 and linux and update the bug.  
nominating this for nsbeta1. 
Keywords: nsbeta1
QA Contact: esther → sheelar

Comment 4

17 years ago
Can you find a recent build where it was faster?  Could the progress dialog
affect this?

Comment 5

17 years ago
I tested on windows98 using the same file (14MB).  It took 1min 42seconds on
trunk build 2001070206. On 4.x it took about 1min 46sec.  So this seems to be
working okay on windows. I still need to check this on linux and will update
after I do.  

I could go back a few builds before the progress dlg and check to see if it was
faster than what it is now.  

Comment 6

17 years ago
the mac probably doesn't like the async smtp feature. We block and restart
threads which the mac doesn't like. That's probably the problem. I suspect we
are just going to have to live w/ it since we don't like the old behavior of
blocking the UI.

Comment 7

17 years ago
With Build 2001070310 MacOS 8.6 14Mo attachment

Operation     Click send    Attaching       Send        Write           Completed
Freeze            |    No      |     Yes     |     No     |       Yes       |
Status Dialog     |    -       |  Attaching  | Deliv.mail | Deliv.mail100%  |
Time              0           0:36          1:36         2:50             7:56

LAN speed when Delivering mail ~340k/s on 10base-t

All the lags are with disk R/W operations...

Comment 8

17 years ago
Here are the few builds that I tried sending the same 14MB file:

Latest 2001062704 trunk build:  4mins 42sec
oldest build I had 2001060506 trunk build: 4mins 59sec

Comment 9

17 years ago
Retry under NS4.77 with exact same Network Congestion/File/Server load as at 
2001-07-03 16:03 --

Complete sequence in 1:21. The write sequence take less than 7 secs. 

Operation     Click send    Attaching       Send        Write           Completed
Time              0           0:01          0:21         1:14             1:21

NS indicate a Read speed of 4750k/s when assembling.
LAN speed when Delivering mail ~360k/s on 10base-t

And no lags/freeze effect on the OS.


Comment 10

17 years ago
Any update on this one? I can't use Moz as emailer as long as this bug is
present...  lose 10 minutes of productivity every time I send something *big*
can cost lot of time at the end of the month! I think for macuser this bug is P1.


17 years ago
Keywords: hang, mail1, perf

Comment 11

16 years ago
*** Bug 98264 has been marked as a duplicate of this bug. ***


16 years ago
OS: Mac System 8.6 → All

Comment 12

16 years ago
Please take at look at Bug 97922.


I'm not sure that Bug 98264 is dup of this one because -> here is with local 
folder Bug 98264 is with IMAP folder : 

> 2. Select Edit | Mail/News Account Settings, set the Sent
> folder to the folder  on an IMAP account. This problem is
> not reproducible when the Sent folder is located in local directory.

Comment 13

16 years ago
I think the time is being spent in nsMsgComposeAndSend::MimeDoFCC(), where we do 
lots of disk I/O in small chunks. I think it could be heavily optimized.
*** Bug 97922 has been marked as a duplicate of this bug. ***

Comment 15

16 years ago
This is a dup of 100353 which has been fixed.

*** This bug has been marked as a duplicate of 100353 ***
Last Resolved: 16 years ago
Resolution: --- → DUPLICATE


16 years ago
Resolution: DUPLICATE → ---

Comment 16

16 years ago
No, it's not. The freeze described here is in disk I/O, as I said above:

>I think the time is being spent in nsMsgComposeAndSend::MimeDoFCC(), where we do 
>lots of disk I/O in small chunks. I think it could be heavily optimized.

Comment 17

16 years ago
oops, my mistake! Thanks simon for the catch.
Target Milestone: --- → mozilla0.9.6


16 years ago
Blocks: 104166

Comment 18

16 years ago
moving to 0.9.7
Keywords: mail1
Target Milestone: mozilla0.9.6 → mozilla0.9.7


16 years ago
Keywords: nsbeta1+

Comment 19

16 years ago
I have identified several locations in the code where we are bloking:

1) When we write parts (nsMsgSendPart.cpp), we read data by block of 4K and then
write it to the temp file line per line, all this is done synchronously.
Unfortunately, it's not a simple task to fix it, it will need a major rewrite.

2) When we prepare a new temp file for the FCC operation (nsMsgSend.cpp). We
read and write line per line, again synchronously. I have a fix for that for
which I'll post a patch soon.

3) during the copy into a local folder (nsLocalMailFolder.cpp). Again a lot of
read/write done synchronously. The best way to fix this part is to be able to
stream the data to copy instead of passing a file. That will remove point #2

Comment 20

16 years ago
Created attachment 57972 [details] [diff] [review]
Proposed fix for temporary freeze while preparing the file to copy, v1

Comment 21

16 years ago
any luck with the patch?
Priority: -- → P1

Comment 22

16 years ago
The patch is covering only 1/3 of the problem. The full solution is way more
complexe and therefore need more time. I think we should push this one to the
next milestone.


16 years ago
Target Milestone: mozilla0.9.7 → mozilla0.9.8

Comment 23

16 years ago
move to 0.9.9 but it will probably not append before 1.0
Target Milestone: mozilla0.9.8 → mozilla0.9.9

Comment 24

16 years ago
Moved post 1.0
Target Milestone: mozilla0.9.9 → mozilla1.2


16 years ago
Blocks: 122274
Keywords: nsbeta1+ → nsbeta1-
No longer blocks: 122274

Comment 25

16 years ago
nominating this for the next release 
Keywords: nsbeta1- → nsbeta1
QA Contact: sheelar → stephend


15 years ago
Blocks: 168430

Comment 26

15 years ago
With build 20020826 I am able to send a 17MB file in 62 seconds.

The only thing that is needed is a dialog while assembling the attachment (bug

Comment 27

15 years ago
Sorry, didn't mention that I'm using Windows NT4 SP6a

Comment 28

15 years ago
*** Bug 184675 has been marked as a duplicate of this bug. ***

Comment 29

15 years ago
What I don't quite understand is why this kind of thing can happen - one thing
is that the process of sending may be disk or CPU intensive or whatever, but it
should not freeze the entire application. Is Mozilla built with a classical
Windows mindset? But even in Windows, nowadays, you can put this kind of process
in a background thread, or even better: in another process. I personally can
live without a real time progress indicator - if there has to be a progress
indicator, either put this in another process, or at least detach the progress
indicator from the I/O process, which can then run in the backkground.

Comment 30

15 years ago
Mail triage team: nsbeta1-
Keywords: nsbeta1-


15 years ago
Keywords: nsbeta1
Product: MailNews → Core

Comment 31

12 years ago
still a problem?

Comment 32

12 years ago
Yes... and no... the write operation (15MB file) takes around 20 secs (whole
process... Click send -> Completed... takes 35 secs) on my PowerMac G4 1.25Ghz
MacOS 10.3.9 (Original report was under MacOS 8.6 PowerMac 8600 G3@400Mhz, my
mail server is now a dual PIII@1.4Ghz instead of a PowerMac 7500@200Mhz and the
network is now 100Base-t). Still during the 20 secs of writing, I can't do
anything else (in Mozilla)... also sometime I get the spinning beach ball and
BTW... Thunderbird is also affected...  but if we (in fact you... because I
don't have the knowledge to fix the problem) wait 3 to 5 more years the Moore's
law will probably do the job... ;-)

Comment 33

11 years ago
do you still see this problem?
there is also bug 358421, bug 240307, and bug 354915

Comment 34

10 years ago
Jean-Francois Ducarroz comment #22
> The patch is covering only 1/3 of the problem. The full solution is way more
> complexe and therefore need more time. I think we should push this one to the
> next milestone.

it's not clear to me what "1/3" of comment 19 is covered by attachment 57972 [details] [diff] [review].

is there more than just the Mac-only portion?

Severity: normal → major
QA Contact: stephend → composition
Summary: Lag and momentary freeze with large attachment → Lag and momentary freeze adding large attachment in compose message

Comment 35

10 years ago
reporter writes "I am now using Thunderbird and everything is fine."  so => WFM
Last Resolved: 16 years ago10 years ago
Resolution: --- → WORKSFORME
Product: Core → MailNews Core
You need to log in before you can comment on or make changes to this bug.