53
edits
Performance:Home Page: Difference between revisions
adding in some page load/dhtml improvements
(starting things off with some notes on startup performance) |
(adding in some page load/dhtml improvements) |
||
| Line 1: | Line 1: | ||
This page is meant to provide a starting point for developers who want to improve performance in Gecko and Firefox. 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. | This page is meant to provide a starting point for developers who want to improve performance in Gecko and Firefox. 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 == | == Startup Performance == | ||
| Line 30: | Line 30: | ||
=== Improve Fastload system === | === 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. | 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. | ||
== 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]]. | |||