Closed Bug 26455 Opened 20 years ago Closed 13 years ago

Mail startup time is slow


(MailNews Core :: Backend, defect, P2)



(Not tracked)



(Reporter: phil, Unassigned)


(Depends on 1 open bug, )


(Keywords: perf)


(2 files)

On Mac: 3.3s on 4.7 vs 15.7s on mozilla. Need to be within 2x to meet beta1
criteria doc.
Keywords: beta1, perf
Whiteboard: [PDT+]
Putting on PDT+ radar for beta1.
All I'll say is...if the browser ain't within 2x 4.7 on startup...we aren't
going to be either...

accepting moving to m14.
Target Milestone: M14
This particular stat covers mail launch time *after* the browser. However, I
understand that it might be the case that DLL loading time dominates in mozilla,
since 4.x loaded all the code up front. *If* it turns out that there's nothing
we can do short of loading all the mail DLLs at startup time, we can resolve
this bug invalid.
P5 for M14.
Priority: P3 → P5
QA Contact: lchiang → suresh
Whiteboard: [PDT+] → [PDT+]UNKNOWN
I have a fix that will get us back .17 seconds on my machine on startup.  It's 
not much, but it's something.  Perhaps close to 1s on a target machine.  I was 
needlessly handling notifications before a folder was even loaded.
I've been Quantifying mail startup through loading my Imap Inbox over the last 
few days and another thing I see taking up time is traversing the file system to 
load local folders as well as imap folders.  

I know that someone should be able to drop in a folder into the pop folder 
hierarchy and have it show up, but I'm wondering if there's a different way to 
do this.  It seems a waste to have to traverse the directories every time when 
most of the time people won't be adding/removing folders outside of 5.0

I'm wondering if we could somehow either use the folder cache or have another 
file that knows about the pop folders and then use something like the subscribe 
dialog for people who are modifying the file system themselves.

On my machine, with about 180 folders I'm seeing close to .5 second being spent 
doing this.  I think that translates to about 2.5 - 4 seconds on the target 
Even though this bug is for the Mac, all of my measurements have been on 
I'm sure mac is still very I/O bound, so this is probably quite relevant.
A question: are we traversing the whole local folder hierarchy even if it isn't
open in the folder pane? seems like we could be REALLY lazy about this...

I think there are times when we just want to know if a folder HAS subfolders,
but not necessarily what they are...I'll bet we could figure that out easily
without actually creating/traversing subfolders.
Hmm. 4.x also discovers all the summary files by traversing the filesystem, and 
it seems to launch pretty quickly. 
I'm not saying it's our only problem.  I'm just saying that I see it standing 
out. I might have all of my folders open right now which is why the number is so 

I don't know if anyone has tried this before, but I tried it this weekend.  I 
made mailnews into one dll.  That's another place where I see us spending a lot 
of time, loading dll's.  I have no idea if this makes any difference.  I'm going 
to ask Suresh to try this out for me.  It did shrink the total size of mailnews 
down by a bit over 200K on an optimized release build and by over 600K on my 
debug build.  And it eliminated 9 dll's. I'm not advocating this approach, I'm 
just curious if it will have any effect.
I still think we should be moving the database "base" classes into
mailnews/base, moving the news database into the News DLL, etc, and we should
handle the inheritance issues via aggregation. 
That would eliminate the database DLL.

Next, we should eliminate the msgbaseutil DLL by moving it's classes into
mailnews.dll, and again solving inheritance issues via aggregation.

Finally, we should combine some of the MIME dlls, such as moving the default
emitters into the base library, and combining the signed and SMIME dlls

If we do all this, we condense 15 dlls down to 10.. 
Hey Scott, Simon Fraser actually already tried doing this on the Mac (where
loading all of these libraries is more expensive than on windows) a couple
months ago.

He discovered that having just a couple shared libraries for the total system
wasn't making a huge dent in the overall startup time of the browser.

You can email him if you want more details about his results. But it didn't look
as promising as he thought it would.

Hopefully this info saves you some time....
Well, I have verified Simon's results :)

One dll vs 10 dll's made no difference in startup time or loading a compose 
window or pretty much anything except size.  

The things I've seen as taking a lot of time in startup based on Quantify:

Loading Dll's

Painting (a ton of time spent saving the clip rect.  I've been told that 
evaughan has a fix that might help change this. Currently 1/3 of painting is 
spent in this - that's .5 s out of 1.5 s on my machine).

File reading.  I'm not sure where this is coming from.  I'm sure it's some combo 
of reading in xul, prefs, and xpt files.

I have no proof of this one except for what I see when Quantifying because it's 
so slow.  But when I Quantify I watch the folder pane come up and see that the 
icons start off really small and then watch it get reflowed about 4 times until 
all of the icons are the right size.  The same thing happens in the thread pane.  
Even if Gecko is really fast, I imagine that this shouldn't be necessary and is 
probably taking up some time.

And then there was the folder hiearchy traversal I mentioned before.
Just to give some stats on file reading. This is from running Quantify starting 
up with -mail and then having my Imap Inbox loaded for me automatically.  No 
password dialog comes up. In the past I've found we can generally multiply my 
results by 5-7 times for the target machine.

nsFileTransport::Process = 1.69 seconds

of which:

nsPipe::nsPipeOutputStream::WriteFrom	= .936 seconds
nsLocalFileSystem::Open	 = .479 seconds 
nsPipe::nsPipeOutputStream::Flush  = .104 seconds
nsLocalFileSystem::GetInputStream = .076 seconds

I believe we were punting on this for PDT. I'm voing to remove the label and let
them decide. But I'm pretty sure we talked about this bug as being a candidate
to cut. Unless scott P. has a miracle up his cap =).
PDT- for beta1
Whiteboard: UNKNOWN → [PDT-] UNKNOWN
Moving my remaining M14 bugs to M15 which is the next targeted milestone.
Target Milestone: M14 → M15
Target Milestone: M15 → M16
Not M16 stopper.  Marking M17.
Target Milestone: M16 → M17
I guess I should change the summary to reflect beta 2.

On the 4/3 build, the timings were 21.096 with a standard deviation of                                                                          
0.104 so the timing has gotten worse.  This is mail startup after starting 

Keywords: beta2
Summary: Mail startup time does not meet beta1 criteria → Mail startup time does not meet beta2 criteria
Keywords: nsbeta2
Putting on [NEED INFO] radar.  PR2 goal is now slower than PR1, how does todays 
commercial build compare to the PR1 final Mac build?  Show us the numbers! ;-)
I didn't have info going back to Beta 1 (mid/late Feb), but I have results from 

3/7/00:  17.568s w/a SD of 0.134
5/4/00:  17.322s w/a SD of 0.195

So we are slightly faster than PR1 (or thereabouts), but very slow compared to 
Putting on [nsbeta2-] radar.  
Whiteboard: [nsbeta2-]
Keywords: nsbeta3
Target Milestone: M17 → M18
Mail triage marking [nsbeta3-]
Whiteboard: [nsbeta2-] → [nsbeta2-][nsbeta3-]
changing summary since it's not just a beta2 problem.
Keywords: beta1mail1
Summary: Mail startup time does not meet beta2 criteria → Mail startup time is slow
marking nsbeta1-.  This isn't one of the top performance areas we are trying to
looking into during the nsbeta1 time period.
Keywords: nsbeta2, nsbeta3nsbeta1-
Whiteboard: [nsbeta2-][nsbeta3-]
Target Milestone: M18 → ---
Blocks: 7251
QA Contact: suresh → stephend
No longer blocks: 7251
Blocks: 7251, 74634
reassigning to cavin and changing platform because startup perf is slow everywhere.
Assignee: mscott → cavin
Blocks: 63759
Keywords: mail1nsbeta1+
OS: Mac System 8.5 → All
Priority: P5 → P2
Hardware: Macintosh → All
Target Milestone: --- → mozilla0.9.7
Target Milestone: mozilla0.9.7 → mozilla0.9.8
Depends on: 117130
*** Bug 89061 has been marked as a duplicate of this bug. ***
investigation on mail startup time will be put off for a while.
Target Milestone: mozilla0.9.8 → mozilla1.2
Blocks: 122274
Keywords: nsbeta1+nsbeta1-
Why does the mailer start _much_ slower than
starting the browser _and then_ the mailer?

Any ideas?
Martin, because the Mail component uses lots of the libraries that Navigator
loads.  So, when launched by itself, it has to load those, but when Navigator
has already been launched, we just load what's left.
Changing milestone as 1.2alpha is done.
Target Milestone: mozilla1.2alpha → ---
Is it possible, at startup of MailNews not to load Local Folders? I have in
Local Folders about 1000 subfolders and 6,3 GB mails in them, which makes
startup time of ~10-20 seconds when connected to LAN (and 5-10 minutes from home
1 MBit VPN connection). Maybe it is worthwile to postpone loading Local Folders
until user (or mail filtering) accesses the Local folders?
Mail sure seems slow lately. It would be great to see this one move forward
before  RC's start coming out.
Product: MailNews → Core
I don't see anything salvageable here.  Do you?
I think none of the suggestions held up after follow up comment(s).

(WRT comment 35, kaido is gone)
Assignee: cavin → nobody
QA Contact: stephend → backend
no, I don't think there's anything salvageable here either.
David comment #38
> no, I don't think there's anything salvageable here either.

David, close bug 117130 also?

Closed: 13 years ago
Resolution: --- → WONTFIX
yes, sure, that could be closed as well, since we don't really use the sidebar.
Um, mail startup time is still slow, though...
Product: Core → MailNews Core
You need to log in before you can comment on or make changes to this bug.