Closed Bug 479078 Opened 15 years ago Closed 14 years ago

Establish why startup can be so slow

Categories

(Toolkit :: Places, defect, P1)

defect

Tracking

()

RESOLVED DUPLICATE of bug 447581

People

(Reporter: sdwilsh, Assigned: agartrell)

References

(Blocks 1 open bug)

Details

(Keywords: perf, Whiteboard: [ts])

Attachments

(1 file)

Trying to establish why startup is slow for some folks.  Possible cause is large history, but it may be something else too.

Getting a profile for this will be a good start at identifying the problem.
Confirmed.

My Firefox 3.0 was starting very slow. I now looked at the preferences and disabled the history at all (it was set for 90 days).

Firefox 3.0 is starting faster now. (But not as fast as FF 3.1 :) )

--Segaja
Dietrich, Shawn mentioned that you might have thoughts on how to obtain (or if
possible) a "large" history file?  Talking to Alex on irc, he can start to work
without one and just use his own, but if there was a known file that he could
use, it would be useful here.
I have my own large places.sqlite that I'd be glad to provide. Bob Clary and Marco also have large history and bookmarks files for testing. Alex, I'll send mail directly with this info.
I sent Alex links to Bob Clary's test profiles yesterday. They're large files on people.mozilla.com, so not making the link public. Ping me and I can send them to you if needed.

Other info/questions:

- Shaver mentioned today that the folks he's talked to said that the very slow startup was after a crash.
- There's anecdotal evidence that clearing history helps. However, we don't know the degree to which it helps.
- We don't know if the browser UI is up or not.
- We don't know if tabs are being restored or not.

Comment #1 said disabling history entirely did help. However, I'm not sure why this would be, since disabling history doesn't affect Places initialization. It only affects whether visits after page load are added to the db (and a few other post-startup tasks).
Priority: -- → P1
Target Milestone: --- → mozilla1.9.1
Flags: wanted1.9.1+
Target Milestone: mozilla1.9.1 → ---
Attached file Testcase Maker?
This python script is a web server that has pages that redirect to one less.  For example, localhost/1000 -> localhost/999 -> ... -> localhost/1 -> localhost/0.  Currently uses javascript redirects.  It's good for creating large profiles.  I'll tweak it to make it resemble typical large user profile better.  Takes optional port argument (so you can navigate to localhost:{somePort}/1000 instead.

Sorry if this is inappropriate?  It seemed test-case-ish enough to share.
Blocks: 489981
Alex: Also check out bug 480340 - it has a patch that generates huge profiles based on stats at https://places-stats.mozilla.com
Flags: wanted1.9.1+ → blocking1.9.2?
My 3.5 beta 4 takes several minutes to start up - it seems to load the plugins ok first, then becomes unresponsive, grinding the hard drive for several minutes until its ready. Earlier 3.5 betas didn't have this problem - the first use of the Awesome Bar took a couple of seconds to fire up, but nothing like it is now.
Alright, so here's the update.

Profilers [basically] work by constantly checking out where the eip is and comparing that against the .text and seeing which procedure it falls under.  Sometimes it even does the fancy thing and climbs the stack, looking at each return address and sees where that is from.  There are, of course, infinite variations of this exist.

On windows, there aren't really any good profilers (google it and hear a million sad stories).  I'm under the impression that they work by following a windows process around or, in some cases, the whole system.  Under linux, you have gprof and qprof and stuff which work as described earlier.  It also demands recompilation with the correct flags and hooks and all that stuff (under linux), which very much changes the whole deal.

The worst thing about it is that Firefox has a lot of different stuff around.  There are lots of shared libraries, which different operating systems handle in different ways.  It often makes more sense to leave a so or dll in memory, just because multiple people might need it, and to evict it as the memory becomes useful.  Thus, replication of the bug is greatly complicated and restarts are often the only way to reproduce.

The good news is, it looks as if windows has a pretty decent profiler suite 'fo free' with the Vista SDK, called Xperf.  Vista, apparently, has all kinds of special hooks in the kernel to facilitate polling, stack crawling, etc. and to try to spot bottlenecks.  As that's the next great hope, I'm looking to find a Vista box to play around w/ as soon as possible.  Unfortunately mine is in Hilliard, Ohio and I am in San Jose, California.  I'll beg and plead for access to one at work and ask around here.

p.s. sorry for the slow feedback. I'll do better :)
You can use xperf to gather traces on XP, but you need a Vista box to analyze the results (long story).

You might also try AMD's CodeAnalyst -- it doesn't have symbol server support until the next version, so you'd have to do your own builds, but my quick test of it was decent enough, and it's free.
Please take note of the work going on in this related bug:
https://bugzilla.mozilla.org/show_bug.cgi?id=480735
I've put together a step-by-step of the approach I'm using to try to create a repeatable test.  Please comment with any thoughts/opinions here or there.

http://alexgartrell.blogspot.com/2009/06/how-to-profile-firefoxs-startup.html
Bug 498079 (and in a way also Bug 498089) is also about slow startup with a different cause than places.
I'm using Firefox 3.1 RC 3 and the browser starts up very, very slowly, MUCH more slowly than Firefox 3.1 RC 2. I hope this gets fixed soon; in the meantime I'll clear my history and see if that helps any.
I think the start is more faster if the page is set to about:blank ,give it a try,i think it's working on Firefox 3.0.0.11.


Thanks.
The good news is that thanks to your suggestion Black Ps` Firefox is now starting quickly for me again.

The bad news is that Firefox freezes now when it starts. At the time I'm typing this it has been frozen for over a minute. Task Manager shows it's using up to 50% of my CPU at times.

I'm using Mozilla Firefox 3.5.
Mine is doing the same thing.  I take it this in an unresolved issue?
When multiple instances of Firefox 3.5 are running, you can open new instances of the program, and they load very quickly.  Even if you have the downloads window open, a new instance of the program will load quickly.  

When all instances of Firefox3.5 are closed, however, it takes approximately 30 seconds to load.  

I have not tried any of the workarounds listed above, since frankly, it should never take this long to load.

Computer = Gateway with Intel Centrino Duo, 2GB RAM, Vista Home Premium.
Depends on: 501605, 502821
this bug should probably stay in General till Places is recognized as a cause.
This bug seems to be an umbrella bug for numerous causes of slowness. 
It should remain in general, and separate bugs should be filed for 
specific causes of slowness.  Those bugs should be marked as "blocking" 
this bug.
Even if places is recognised as a cause, it'd probably to to make another bug blocking this as a meta bug for places slowness. Firefox has been criticised for it's start up slowness long before places.
Depends on: 491283
Keywords: perf
Whiteboard: [ts]
3.5.1 seems to have resolved this problem for me. Appreciate the work on the various issues.
No longer blocks: 489981
Not going to block on a meta-bug, although we'd certainly to like to find and fix additional causes of slowdown.
Flags: blocking1.9.2? → blocking1.9.2-
FYI, friends on Facebook have been talking about dropping FF for Safari and other browsers because of this (meta)-bug alone. I'm on Windows, running 3.5.2, and startup is deathly slow for me too. I'm trying the smaller history thing, but it's not clear if that's the issue anymore. Friends report that that doesn't help. And also that the 3.5.1 update seems to have made things worse, not better. The lack of a splash screen (which would ideally be superfluous) means that you can't even tell whether the app will run at all.
Re: comment 16, I'm seeing the same thing --FF frozen for a (couple) minute(s)--, but in my case I know it's caused by the Weave and (most notably) Xmarks extensions.

Re: comment 17, you can't open multiple instances of the Firefox process, unless you explicitly specify the -no-remote command-line option.  What you're describing sounds very much like you're just opening new windows.  Those new windows still belong to the same process, so there's no initialization and thus much less waiting time.

Other than that, regularly VACUUMing my databases does help on my machine.  That, and disabling any extension I'm not constantly using.

And finally, re: comment 24, you know there's a splash screen extension?
https://addons.mozilla.org/firefox/addon/2995
I'm duping this in favor of bug 447581 to track startup bugs. See also https://wiki.mozilla.org/Firefox/Projects/Startup_Time_Improvements.
Status: ASSIGNED → RESOLVED
Closed: 14 years ago
Resolution: --- → DUPLICATE
No longer depends on: 491283
Blocks: 447581
You need to log in before you can comment on or make changes to this bug.