Confirmed users
945
edits
Performance/Addons/BestPractices: Difference between revisions
Correct MDN link
(Adding suggestions by Nils Maier) |
(Correct MDN link) |
||
| (9 intermediate revisions by 5 users not shown) | |||
| Line 1: | Line 1: | ||
This page has MOVED to MDN: | |||
[https://developer.mozilla.org/en/Extensions/Performance_best_practices_in_extensions MDN: Performance Best Practices in Extensions] | |||
A list of recommendations for add-on authors to help keep Firefox fast and responsive. | A list of recommendations for add-on authors to help keep Firefox fast and responsive. | ||
==Use JavaScript Modules== | ==Use JavaScript Modules== | ||
| Line 49: | Line 48: | ||
(Examples cribbed from the [[Performance/Optimizing_JavaScript_with_DTrace|DTrace page]].) | (Examples cribbed from the [[Performance/Optimizing_JavaScript_with_DTrace|DTrace page]].) | ||
== Avoid Writing Slow CSS == | |||
# Read [https://developer.mozilla.org/en/Writing_Efficient_CSS the "writing efficient CSS" guide]. | |||
# Remember that any selector in your rule which might match many different nodes is a source of inefficiency during either selector matching or dynamic update processing. This is especially bad for the latter if the selector can dynamically start or stop matching. Avoid unqualified ":hover" like the plague. | |||
==Lazily Load Services== | ==Lazily Load Services== | ||
| Line 62: | Line 65: | ||
TODO: Give examples below, link to code, bugs, docs. | TODO: Give examples below, link to code, bugs, docs. | ||
* | * If you're targeting Firefox 3.6 and earlier, or if you're specifying em:unpack then use chrome JARs! | ||
* Combine CSS | * Combine CSS | ||
* Combine pref files | * Combine pref files | ||
| Line 79: | Line 82: | ||
==Unnecessary onreadystatechange in XHR== | ==Unnecessary onreadystatechange in XHR== | ||
addEventListener(load/error) | addEventListener(load/error) and/or xhr.onload/.onerror are usually sufficient for most uses and will only be called once, contrary to onreadystatechange. | ||
When using XHR in websites people tend to use onreadystatechange (for | When using XHR in websites people tend to use onreadystatechange (for | ||
compatiblity reasons). Often it is enough to just load the resource or handle errors. load/error event listener are far less often called than onreadystatechange, i.e. only once, and you don't need to check readyState or figure out if it is an error or not. | compatiblity reasons). Often it is enough to just load the resource or handle errors. load/error event listener are far less often called than onreadystatechange, i.e. only once, and you don't need to check readyState or figure out if it is an error or not. | ||
Only use onreadystatechange if you want to process the response while it is still arriving. | |||
==Removing Event Listeners== | ==Removing Event Listeners== | ||
| Line 92: | Line 97: | ||
var largeArray; | var largeArray; | ||
addEventListener('load', function() { | addEventListener('load', function() { | ||
removeEventListener('load', arguments.callee, true); | |||
largeArray.forEach(); | |||
}, true); | }, true); | ||
| Line 110: | Line 115: | ||
==apng/agif inappropriate in a lot of cases== | ==apng/agif inappropriate in a lot of cases== | ||
Animations require a lot of time to set up ( | Animations require a lot of time to set up, as a lot of images are decoded (the frames). | ||
nsITree/<tree> seems to be extra special in this regard, as it seem to | Animated images may have their cached representations evicted quite often, causing the frames of your animated images to be reloaded lots of times, not just once. | ||
nsITree/<tree> seems to be extra special in this regard, as it doesn't seem to | |||
cache animations at all under certain circumstances. | |||
==base64/md5/sha1 implementations== | ==base64/md5/sha1 implementations== | ||
Do not ship own base64/md5/sha1 implementations. | Do not ship your own base64/md5/sha1 implementations. Regarding base64 there are the built-in atob/btoa functions that do the job just well and are available in overlay script as well as in in js modules and components. Hashes can be computed using nsICryptoHash, which accepts either a string or an nsIInputStream. See the [https://developer.mozilla.org/en/nsICryptoHash MDC documentation for nsICryptoHash] | ||
==Image sprites== | ==Image sprites== | ||
| Line 127: | Line 133: | ||
The latter is admittedly difficult to get right (no DOM access, store references to avoid garbage collector hazards). Web workers are far less "dangerous". See MDC for some examples. If you use threads then make sure to test on a multi-core system. A single core system will hide crashed. | The latter is admittedly difficult to get right (no DOM access, store references to avoid garbage collector hazards). Web workers are far less "dangerous". See MDC for some examples. If you use threads then make sure to test on a multi-core system. A single core system will hide crashed. | ||
Please note that as of Firefox 4, nsIThread.dispatch does not accept nsIRunnable-s implemented in Javascript and created on a different thread than the thread you're trying to dispatch the nsIRunnable to. This limitation was implemented to avoid crashes caused by changes especially to the Javascript strings implementation. | |||
This effectively means that javascript extensions cannot use the nsIThread API anymore to execute own jobs on different threads than the main thread. | |||
Consider Web/ChromeWorker as a replacement, which are severely limited in what you can do with them, or just don't use threads. | |||