Firefox, Extensions and Performance
Posted: March 10, 2010 Filed under: firefox, mozilla | Tags: extensions, firefox, Performance 24 CommentsExtensibility is a double-edged sword. It’s a keystone feature in Firefox – differentiating even now that just about every other browser has some vector for augmentation. However, along with the freedom and power of Firefox extensions comes the ability to slow the browser down. And worse, users and developers have little or no visibility into the causes of poor extension performance.
Not all extensions slow Firefox down. But they can. To prevent that, we need to do three things:
- Make it *easy* for extension developers to keep their extensions fast.
- Allow users to see the performance effect of their extensions.
- Mitigate the effects of badly-behaving extensions in Firefox itself.
For Extension Developers
First, we need to loudly and clearly educate extension developers, and provide them tools. Some ideas:
- Write an extension performance “best practices” guide on MDC.
- Build warnings into Firefox, that highlight code that might perform poorly (bug 550242).
- Provide a try-server that allows extensions to be uploaded and installed into the test profile.
- Perform automated performance testing of extensions upload to AMO (bug 458990, maybe?)
- Ensure that Jetpack generates extensions that are models for good behavior.
For Users
Users should be able to make informed choices about the extensions they install, and be able to monitor the effect of extensions on their browsing sessions. We could:
- Provide performance information for extensions on their pages on AMO.
- Build a performance dashboard similar to about:memory, but tracking startup time, page-load time, and browser UI behavior such as menu responsiveness. Given a visualization of these things over time, users can see the effects of installing different extensions.
In the Core
There are also things we can do to mitigate poor performance in core Firefox code. This is being discussed in bug 533038.
We’re already working on some of the ideas listed above. Ping me in #startup on irc.mozilla.org if you want to help out. If you have ideas for other ways to improve extension performance, or to communicate back to users and developers, let me know in the comments.
dietrich.ayala 
Attacking performance with a set of ‘rules’ of thumb, but then instrumenting the user’s browser for performance set the stage for a lot of angry extension users and developers. You are encouraging users to complain about problems that developers have no means to fix.
If you provide developers with a quick and effective performance analysis tool, they will use it if they believe it makes a difference for their users.
So then you only need to convince them that cold start up time is important. (I’ve never heard any user of Firebug complain about start up time).
> You are encouraging users to complain about problems
> that developers have no means to fix.
A best practices guide provides the tools for developers to fix performance problems in their extensions.
I agree, Its important to provide choice for both developer and user to see how addon is performing. May be user is Okay with poor performance for utility it wants. It should not become a nagging point for developers so users keep pinging them. First priority should be there for developer tools. But user choice does matter as increasingly (especially geeks) complain about FF for for memory usage and slow performance. Lot of time its addon which is making it slow.
Sure, maybe it’s not on the main details page of an extension, but it should be available in some form, somewhere, so that users can make educated choices, and developers are encouraged to rectify problems.
What is actually discussed in bug 533038 is that how extensions are (un)packed can also influence the performance of FF. In short, unpacking all the files of the extension in the profile directory does impact the startup time of FF. It would be a good idea if AMO would check the packaging of the extension/theme to check if the files are kept together in the jar file.
(simply check the amount of references in chrome.manifest)
Yes, keeping the files in a JAR is very important for performance. At the very least, extension reviewers should check that files are in JARs, and if not should encourage developers to do so.
One problem is that the latest extension developer documents and much recent advice on the net is to eschew JAR files and deliver your extension files in unJARed format.
Phil
@Jigar shah Excellent points about the complaints that users have about Firefox: too big and slow. My users complain about these problems a lot: that is the area where we need help! We don’t need help with cold startup, our users don’t care.
@Alfred Kayser No! Please no more AMO roadblocks! The jar packing makes more work for extension devs and provides no value to users. If our users ever complain about start up time we can easily fix it by lazy loading.
Both cold and warm startup are known problems with Firefox on the major platforms, and worse on mobile platforms.
Re: JAR files – please read the bug Alfred references. JARing files is not work, and makes a big difference in performance. As we move forward with projects like Jetpack, making extensions will be even less manual, and steps like JARing files can be automated.
@Alfred Kayser …but how about AMO reading the chrome.manifest and if the sub-directories are not jarred, AMO can jar them and re-write the chrome.manifest! That way we get the advantage but not the work.
That’s a great idea. I’ll file a bug for this.
filed: https://bugzilla.mozilla.org/show_bug.cgi?id=551714
Would be good if AMO had a performance detail part with :
– this extension slows down cold/hot startup by xxx ms
– this extension slows down page loading by xxx ms/percent
– this extension slows down javascript executing by xxx ms/percent
Extension developers would be up in arms about enhancing their extension or getting the Firefox bugs that make the slowdown unavailable fixed.
[…] performance work I mentioned last week, and got a conversation going, with posts by Taras, Asa and myself. I’ve listed the various ideas and approaches that came out of those posts and comments here. […]
Perhaps the way to do this is to have a “performance impact” on Firefox start up – eg this extension will add 100ms or 5% delay to Firefox start up. The figure could be added to the extension from a “reference test” set at Mozilla – and be part of the “approval” process – with the extension developer being able to see the “report” so they could decide to “tweak the code” before its approved to the public?
[…] Řada uživatelů Firefoxu má nainstalováno nějaké to rozšíření, které přidává zajímavou funkčnost. Takto nainstalovaná rozšíření však mohou být i zdrojem problémů. Nejčastějším řešením problému bývá zakázání či odinstalace problematického rozšíření. Jak ukázal jeden vývojář, mohou být rozšíření i zdrojem pomalého startu Firefoxu. Příčiny přitom mohou být různé. Může se jednat o špatně napsané rozšíření, o rozšíření, které je komplexní a při startu vyžaduje určitý čas na inicializaci, případně může být problém i v samotném Firefoxu. V Mozille se snaží tuto situaci zlepšit. […]
* Startup Performance
Slow Firefox Startup Performance is 99% related to the number of tabs a user has open.
At least that is the experience of my circle of friends.
I installed “Bar Tab” and no longer have _any_ delay at startup regardless of the number of tabs open.
Of course this could be regarded as a “cheat” as the pages are only loaded on use… but user perception is “Hey that’s lightning fast!”.
* Extensions Performance
How about Mozilla doing a code review on the top 100 extensions and offering the developer patches to fix any outstanding issues? You could award the extension a “Plays Nice With Others” badge on AMO as a sweetener.
Once the top 100 are done offer the service to others.
If Mozilla can not devote the resources for a full 100 do the top 20.
I support the idea of Nigel : If some of the extensions add a long delay, I’ll uninstall them if I don’t use them often or keep them if I truly need them.
This will help users to do some cleaning of the installed extensions.
There are “mandatory” extensions : check-speller dictionaries : the English/US for practically everybody, the local dictionaries in each country. Is it possible to optimize them ?
To SilverWav
Thanks for “Bar Tab” …
[…] for chrome files to be packed in a JAR file, which remains packed after installation. According to recent discussions about add-on performance, it’s more efficient to keep files packed together. Instead of requiring authors to use the […]
[…] Firefox, Extensions and Performance « dietrich.blog (tags: firefox extension) […]
[…] laid out in the file system after installation. The suggestion is to educate developers on how to package add-ons taking performance into account. That’s not a bad approach, but I think it’s easier for developers and more effective […]
[…] began the add-on performance conversation with his post Firefox, Extensions and Performance, and now with the help of Heather Arthur, we have a modified Talos system measuring the startup […]
Code modules of course offer great potential, e.g., for loading classes just once. This should also help extensions speed up opening of extension dialogs. However, debugging these is a pain for the same reason that it is an advantage–if it only loads once, one can’t change some code and see it work again. If the feature at https://bugzilla.mozilla.org/show_bug.cgi?id=481603 were added, developers could refresh a module’s code programmatically when they are debugging.