Confirmed users
945
edits
Performance/Addons/BestPractices: Difference between revisions
Correct MDN link
(→Reduce File I/O: Jars are not necessary for fx4+ (without em:unpack)) |
(Correct MDN link) |
||
| (5 intermediate revisions by 3 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 83: | 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 114: | 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 134: | Line 136: | ||
This effectively means that javascript extensions cannot use the nsIThread API anymore to execute own jobs on different threads than the main thread. | 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. | Consider Web/ChromeWorker as a replacement, which are severely limited in what you can do with them, or just don't use threads. | ||