Performance:Home Page: Difference between revisions

From MozillaWiki
Jump to navigation Jump to search
No edit summary
(Redirected page to Performance)
 
(21 intermediate revisions by 2 users not shown)
Line 1: Line 1:
This page is meant to provide a starting point for developers who want to improve performance in Gecko and Firefox.
#REDIRECT [[Performance]]
 
This page was last updated March 18, 2010.
 
=Dashboard=
 
* Per-branch graphs over time
** [http://graphs.mozilla.org/dashboard/?tree=Firefox3.5 Firefox 3.5]
** [http://graphs.mozilla.org/dashboard/?tree=Firefox3.6 Firefox 3.6]
** [http://graphs.mozilla.org/dashboard/?tree=Firefox Trunk]
* [http://graphs.mozilla.org/dashboard/snapshot/ Cross-branch comparison snapshot]
 
=Projects=
 
* [[Firefox/Projects/Mobile_Startup_Shrink|Mobile Startup Shrink]]
* [[Firefox/Projects/Startup_Time_Improvements|Startup Performance]]
* [[Firefox:FrontEndPerformance|Front-end Performance]] (i.e., responsiveness)
* [[Performance/Addons|Add-on Performance]]
* [[Performance/MemShrink|MemShrink]]
* [[Performance/Snappy|Snappy]]
 
= Tools =
 
* [[Codesighs]] - a tool which analyzes code and data size.
* [[Performance:Tools]]. For measuring performance. Tip o' the propeller-cap to [mailto:zuperdee@penguinpowered.com Daniel Roberts] (zuperdee@penguinpowered.com) for the pointers.
* [[Performance:Probes]]. Project to integrate a system of performance probes into Gecko.
 
= Tests =
 
The [[Performance:Tinderbox_Tests]] are commonly used as a benchmark of Mozilla performance.
 
= Documentation =
 
* Code Footprint [[Performance:Footprint_Reduction_Techniques]] explains common bad patterns and how to correct them.
* [[Performance:Profiling_JuJu]]. Things you should know about doing profiling. Tips and tricks for some of the tools, and lots of other Good Things To Know.
* [http://www.mozilla.org/performance/mac-performance.html Profiling and leak analysis] on the Mac.
 
= Tool Presentations =
 
* [[Performance:Footprint_Tools]]. Presentation on footprint tools
* [[Performance:Startup]] [http://www.mozilla.org/performance/perf-intro/slide1.xml slides] Presentation on general performance tools
* [[Performance:Leak_Tools]]. Presentation on memory leaks detection tools
* [http://www.mozilla.org/performance/mac-performance.html Mac Performance Tools] Presentation on performance tools that work on Mac
 
= Task Lists =
 
Somewhat ordered in descending probability of being useful, based on an inexperienced observer. They are labeled with an approximate range starting when the tracking bug was opened to that latest activity on the tracked bugs, to make it easier to recognize stale or obsolete tracking bugs. The current pass was done in 2010, which is why you'll see "2010+" as the end of the range for some of these. (If you are reading this in a year after 2010, please feel free to update those ranges to either "2010" if activity has pretty much ended, or "2012+" if it is still going on in the year 2012.)
 
* Performance issues
** {{bug|447581}} - tracking bug: startup performance ''from 2008-2010+''
** {{bug|134576}} - tracking bug: XUL fastload ''from 2002-2009''
** [https://bugzilla.mozilla.org/buglist.cgi?keywords=topperf&resolution bugs with topperf keyword]
** [https://bugzilla.mozilla.org/buglist.cgi?keywords=perf&resolution bugs with perf keyword]
** [https://bugzilla.mozilla.org/buglist.cgi?keywords=mlk&resolution=--- memory leak bugs]
** {{bug|191033}} - tracking bug: embedding code size reduction ''from 2003-2007''
** tracking bugs: Cairo performance issues
*** Windows: {{bug|334719}} ''from 2006-2010+''
*** Unix: {{bug|334720}} ''from 2006-2010+''
*** Mac: {{bug|334721}} ''from 2006-2010+''
** {{bug|384323}} - tracking bug: UI responsiveness - core/platform ''from 2007-2008''. Odd; I would expect this one to be up to date.
** {{bug|384325}} - tracking bug: UI responsiveness - applications
*** {{bug|91351}} - tracking bug: UI/App responsiveness issues ''from 2001-2005, moved under {{bug|384325}}''
** {{bug|71668}} - tracking bug: page loading performance issues ''from 2001-2002''
** {{bug|98275}} - tracking bug: xpcom perf ''from 2001-2002''
** {{bug|500489}} - tracking bug: Slow performance on this DOM manipulation testcase ''from 2009-2009, with single fixed child bug only''
** {{bug|384115}} - tracking bug: Mozilla 2 "exploiting hardware parallelism" (largely useless as a tracking bug; the discussion is offtopic and it ends up only pointing to electrolysis. Nothing about GPUs or threads or overlapping I/O.)
** {{bug|49141}} - tracking bug: New window performance ''from 2001-2007''
** {{bug|103712}} - tracking bug for Mozilla 1.0 performance
* Tooling/Benchmarks
** {{bug|499198}} - tracking bug: Peacekeeper benchmark ''from 2009-2010''
** {{bug|307312}} - tracking bug: startup with WAY_TOO_MUCH_GC ''from 2005-2008; not sure how much is left after conservative stack scanning for GC is taken into consideration''
** {{bug|377787}} - tracking bug: Cycle collector performance ''from 2007-2008''
** {{bug|72677}} - tracking bug: putting timer hooks in app code for performance measurement ''from 2001-2001''
 
== Individual Bugs ==
 
These should probably be moved under a tracking bug
* {{bug|170284}} - request for page-specific performance stats
* {{bug|505104}} - request for add-on performance impact display
* {{bug|551598}} - GC performance analysis
 
= Tasks =
 
The list below focuses on the performance projects that we think will have the biggest impact.  Each task includes a brief description and links to additional resources.  The tasks are grouped by performance area but are otherwise in no particular order.
 
== Startup Performance ==
 
=== Reduce startup workload ===
We should be able to greatly reduce the amount of work needed to bring up the Firefox browser window.  Today, it loads a bunch of extra stuff that really could be delayed until it is needed.  Phoenix 0.1 started up very quickly because it was a simple XUL browser! ;-)
 
Possible areas for improvement:
* Put components which aren't typically needed at startup into external dlls, to reduce the amount of code that has to be paged in
* Fastload XBL bindings
* ...
====PUT all in one File====
NO extra DLLS and no DLLS
because current harddrives load 40 to 80 MB per second but only if it is one big file and second manage internaly what classes are instantiated and loaded into workingmemory only whats needet to see the browsers userinterface.
pleas make a version without script for users the dont care about (99%)
--nonkapitalist 14:46, 16 August 2006 (PDT)
---
Typically one would put the mandatory for first page functions in one DLL then divide up other functions into DLL's that can load quickly on demand.  Needing to access multiple DLL's to display the first screen, I agree would generate unnecessary drag.
 
=== Move FF to XULRunner (investigate at least) ===
A trimmed down XUL browser application based on xulrunner loads much more quickly than FF 1.5, and uses significantly less memory (on the order of 14 vs 26 megabytes of memory).  We need to understand why, and more importantly figure out how to trim the size of FF's memory footprint accordingly.  This may mean moving FF to xulrunner, or it may mean applying something else that we learn from the investigation.  At any rate, we know it should be possible to show the user's homepage using significantly less memory than we do now, which should help startup performance.
 
=== Preload FF at system start ===
Bring back Mozilla quick launch, but do it better ;-)  Possibly build an extension that could be used with FF 1.5 to enable this functionality.
 
=== Javascript Component Loading ===
Even with fastloaded (precompiled) javascript components, we spend a fair amount of startup time deserializing large scripts.  Things to do:
* Refactor large components (nsExtensionManager.js, nsUpdateService.js) to load the minimal amount of code at startup
* Eliminate locking in the JS engine when deserializing scripts, see {{bug|312238}}
* Use a large pool of memory for allocating strings during deserialization, see {{bug|279839#c11}}
 
=== Function Ordering ===
All of the major platforms support having the linker reorder functions in the binary.  We can exploit this to move the functions that are needed at startup into a contiguous section at the start of the binary, which should reduce the time spent reading from disk.
* Profile the startup process to generate an optimal function ordering
* Integrate the ordering into the build system
---
* Might also want to see if anything in the startup sequence can be parallelized...
 
=== Improve Fastload system ===
 
The Fastload system is used to load precompiled javascript, preparsed XUL, and soon preparsed CSS at startup.  The system is currently designed to be architecture-independent, which makes it impossible to write large chunks of memory at once (differences in endianness, data sizes, and struct packing).  We could drastically reduce the time spent reading the fastload file by changing to an architecture-dependent, memory-mapped file that could be accessed directly.
 
Tracking: {{bug|134576}}. No bug for architecture dependence found.
 
== Page load and DHTML Performance ==
 
=== Optimize XPConnect Locking ===
XPConnect does a lot of locking for threadsafety despite the fact that 99% of callers are on the main thread.  We should optimize this for the common case.  This should directly impact DHTML performance.  For more information, see https://bugzilla.mozilla.org/show_bug.cgi?id=307953 .
 
=== Optimize for the main application thread ===
99% of the work done by Gecko happens on the main thread, and yet many of the core pieces of Gecko are written to be fully threadsafe.  This includes core XPCOM components, XPConnect, and portions of Necko.  There is also an overuse of threadsafe reference counting (using atomic increment/decrement).  We can shift more of the performance burden on background threads by using proxy objects when accessing "main thread only" objects on background threads.  We can do this today with some hardcoding of NS_GetProxyForObject, but it would be better if object proxification were automated.  For example, getting a component from the component manager on a background thread should result in a proxy to the real object if the object only wishes to be invoked on the main thread.  This will allow us to more easily streamline main thread object access while preserving support for those infrequent background thread use cases.
 
=== Request Prioritization ===
Necko has support for prioritizing requests to the same host relative to each other.  We can make use of this to give on-screen content higher priority than off-screen content.  Images, plugins, iframes, etc. could benefit from this.
 
=== Other areas for investigation ===
These ideas are less well-defined than the ones above, but may be good starting points:
* Reuse the scrollbars and associated objects between pages.  Currently, these are recreated on each load.
* Experiment with the timing of initial layout and paint.  We may be able to help at least perceived performance by trying to get a full screen of content displayed as fast as possible (but without "jumping").
* Optimize the way that HTML reflow works.  See [[Gecko:Reflow_Refactoring]].
* Investigate better strategies for allocating memory for DOM and layout objects.
* Other items listed at [[Gecko:Layout_Improvements]].
* XPConnect currently makes JS -> C++ calls via xptcall, which is really an interpreter. Could we identify common method signatures and created compiled translation stubs for important platforms?
 
== Mobile Related Issues ==
 
[http://wiki.mozilla.org/Mobile/Performance Mobile Performance Info]
 
= Other Related Projects =
 
* (ARCHIVED) [http://www.mozilla.org/mailnews/win_performance_results.html Mail-News Performance Statistics]. A history of our mail-news performance stats.
* [http://www.mozilla.org/xpapps/performance XPApps Performance. The browser performance effort.
* [[Performance:References]]. A dumping ground for performance-related links and documents.
* [http://www.mozilla.org/community.html Community]. [news://news.mozilla.org/netscape.public.mozilla.performance netscape.public.mozilla.performance] is the Mozilla performance newsgroup, and [mailto:mozilla-performance@mozilla.org mozilla-performance@mozilla.org] is an e-mail mirror.

Latest revision as of 20:23, 19 April 2013

Redirect to:

Retrieved from "https://wiki.mozilla.org/index.php?title=Performance:Home_Page&oldid=648109"