Closed
Bug 675233
Opened 14 years ago
Closed 6 years ago
Profile: break up startup into a timeline
Categories
(Firefox for Android Graveyard :: General, defect, P1)
Firefox for Android Graveyard
General
Tracking
(Not tracked)
RESOLVED
WONTFIX
People
(Reporter: stechz, Assigned: stechz)
Details
(Whiteboard: mobilestartupshrink)
Attachments
(2 files, 4 obsolete files)
|
8.86 KB,
patch
|
Details | Diff | Splinter Review | |
|
2.28 MB,
text/html
|
Details |
This patch allows you to see at what point in startup a component has been initialized. You might find this useful for figuring out the bottlenecks in our startup code.
| Assignee | ||
Updated•14 years ago
|
Whiteboard: mobilestartupshrink
| Assignee | ||
Comment 1•14 years ago
|
||
| Assignee | ||
Comment 2•14 years ago
|
||
This is just an HTML file that can read the output of the above patch and figure out where the biggest time delays are.
| Assignee | ||
Comment 3•14 years ago
|
||
Here are the results for my phone, on "cold startup." Here is how I got these results:
* Load your Fennec and launch adb logcat
* Open Firefox 5 and load http://tbpl.mozilla.org/?tree=Firefox :)
* In logcat, you should see that the Fennec process is killed. If not, load more tabs!
* Hold down home button, select Fennec.
* The results will be in adb logcat
These results are with some of my startup patches that delay SQLite loading as long as possible, and it uses a very small XUL file that then loads the browser.
Some noticeable hotspots from this:
* something between gfx/info and gfx/init takes 224ms
* addons-integration seems to be taking 187ms
| Assignee | ||
Comment 4•14 years ago
|
||
New script uses previous event instead of next event in difference finding, which tends to be more useful. Also, converts microseconds to milliseconds.
Attachment #549399 -
Attachment is obsolete: true
| Assignee | ||
Updated•14 years ago
|
Summary: Profiling: show time elapsed after main when a new component is initialized → Profile: break up startup into a timeline
| Assignee | ||
Updated•14 years ago
|
Priority: -- → P1
| Assignee | ||
Updated•14 years ago
|
Assignee: nobody → ben
| Assignee | ||
Comment 5•14 years ago
|
||
| Assignee | ||
Updated•14 years ago
|
Attachment #549398 -
Attachment is obsolete: true
| Assignee | ||
Updated•14 years ago
|
Attachment #549465 -
Attachment is obsolete: true
| Assignee | ||
Updated•14 years ago
|
Attachment #549405 -
Attachment is obsolete: true
| Assignee | ||
Comment 6•14 years ago
|
||
HTML output from the parser uploaded here:
https://github.com/stechz/Mobile-Firefox-Startup-Profiler
I'm not 100% confident in these numbers, but they can be verified by looking at the logs. Some interesting notes:
* Total time to first paint was just over 10 seconds
* About a fifth of the time was before main
* XPTI parsing took 476ms
* The recorded JS running/parsing took 1197ms
* XUL parsing is accidentally missing from the log output of this patch but looks to be about 582ms
* The recorded layout stuff: 468ms + 507ms + 188ms
| Assignee | ||
Comment 7•14 years ago
|
||
Hm, not sure where the XUL parsing went. There is no record of nsXULPrototypeDocument::Read at all. This patch ignores any logs off the main thread, so perhaps it is conditionally read async?
Comment 8•14 years ago
|
||
with functiontimers, you should be able to look at the vtable pointer for the runnables processed on the event queue to get a better understanding of what events take the longest to process.
Comment 9•14 years ago
|
||
I had a look at the example:
This log hunk gets called gfx loading fonts and is assigned a value of 152ms. However,
it looks gfxPlatformFontList::Init only takes 38ms. What's going on here?
I/Gecko ( 7202): [default 4439.00] > ( 10) |?MINMS virtual nsresult nsComponentManagerImpl::GetServiceByContractID(const char*, const nsIID&, void**) (line 1649) (contractid: @mozilla.org/gfx/info;1) I/Gecko ( 7202): [default 4439.00] > ( 11) |?MINMS virtual nsresult nsComponentManagerImpl::CreateInstanceByContractID(const char*, nsISupports*, const nsIID&, void**) (line 1253) (contractid: @mozilla.org/gfx/info;1) I/Gecko ( 7202): [default 4440.00] < ( 11) |<MINMS 1.00 ms ( 1.00 ms total) - virtual nsresult nsComponentManagerImpl::CreateInstanceByContractID(const char*, nsISupports*, const nsIID&, void**) (line 1253) (contractid: @mozilla.org/gfx/info;1) I/Gecko ( 7202): [default 4440.00] < ( 10) |<MINMS 1.00 ms ( 1.00 ms total) - virtual nsresult nsComponentManagerImpl::GetServiceByContractID(const char*, const nsIID&, void**) (line 1649) (contractid: @mozilla.org/gfx/info;1) I/Gecko ( 7202): [default 4543.00] > ( 10) |static nsresult gfxPlatformFontList::Init() (line 67) I/Gecko ( 7202): [default 4581.00] < ( 10) | 38.00 ms ( 38.00 ms total) - static nsresult gfxPlatformFontList::Init() (line 67) I/Gecko ( 7202): [default 4591.00] > ( 10) |?MINMS virtual nsresult nsComponentManagerImpl::CreateInstanceByContractID(const char*, nsISupports*, const nsIID&, void**) (line 1253) (contractid: @mozilla.org/gfx/init;1)
Comment 10•6 years ago
|
||
Closing all opened bug in a graveyard component
Status: NEW → RESOLVED
Closed: 6 years ago
Resolution: --- → WONTFIX
You need to log in
before you can comment on or make changes to this bug.
Description
•