Firefox扩展：性能：覆盖与自举

Question

I understand the convenience of installing bootstrapped extensions but there is a question that has been bugging me for a long while.

Has there ever been a performance & resource/memory usage comparison between overlay & bootstrapped extensions?

In overlay extensions, a lot of the work, ie XUL overlays etc are handled NATIVELY by the application (ie Firefox). In a bootstrapped extension, all above work is left to the extension developer which often involves manually adding many event-listeners and observers to achieve the same (which could be not as native as the applications core).

I have noticed startless addons that fail to initiate on occasions on some windows. I have also noticed startless addons that on occasions, the insertion itself was noticeable (ie the functionality, image, icon comes slightly after the window is loaded). Furthermore, the type of the even-listener used is not uniform and varies greatly.

I have a nagging feeling that manually (and not natively) adding menus, context menus, functions, string-bundles, preferences, localization etc and Enumerating windows would use more resources (besides the fact that its efficiency would be greatly dependent on developer's skills).

I look forward to your comments :)

Answer 1

How an add-on performs mostly depends on the actual implementation (what the add-on does and how) and data it keeps around. As such you cannot really just compare performance of overlay vs. restartless add-ons.

I converted add-ons from overlay to restartless ones that performed better afterwards, because I optimized some things along the way. The opposite might be true, of course, in other cases.

Memory consumption depends on what the add-on does, incl. how many event listeners it creates. Unless you create thousands upon thousands of event listeners (that also pseudo-leak stuff in closures), the memory consumed by these listeners is usually negligible as about:memory will tell you. You can have memory hungry overlay add-ons and lightweight restartless add-ons, or vice-versa.

You're right hat the efficiency depends greatly on the skills a developer has, ie the quality of the implementation and data structure designs which is usually directly correlated with said skills.

• It is easy to create a simple "button" SDK add-on, but the SDK has lots and lots of abstractions to make it easy, and these abstractions consume resources (memory, CPU or even file I/O).
• It is a bit harder to create an equivalent overlay add-on, but still you get quite a few things for free ( overlay , style ). These niceties are higher-level abstractions, too, and come at a cost.
• It is quite difficult to create an equivalent bootstrapped add-on, but if done correctly it might outperform the other add-on types, even during startup (no chrome.manifest to read, parse and interpret, no sync loading of overlays and associated styles, etc.)

It's a bit like comparing C (restartless) to Java (overlay) to Ruby (SDK). People love the convenience of Ruby, but proper Java code easily outperforms it. Then again, Java will often outperform equivalent C programs written by novice developers (also those novice developers will more likely leak memory all over the place ;), but a C program written by skilled developer may outperform Java.

What you're asking here is essentially indicative of premature optimization . Instead code, measure and then optimize if necessary and according to your skill levels.

Once you notice that your add-on consumes tons of memory or runs slowly, then measure and/or debug the cause. Or just measure pro-actively. The point is: measure .

If it isn't your add-on that misbehaves, tell the author, or file a tech evangelism bug if it is real bad.

Since you ask about DOM manipulation/overlays, addEventListener vs. "native":

• Overlays may be faster than calling a bunch of DOM methods from JS. But then again, overlays are XML and need to be read from disk, then parsed into a DOM, then the DOM needs to be merged with the DOM that is overlaid, following all kinds of rules, etc. That requires all kinds of I/O, (temp.) memory, CPU, etc. So overlays may be slower. Depends on the overlay.
• addEventListener is usually blazingly fast. In fact, overlay "event" listeners, (those nasty oncommand / onclick / onwhatever attributes), use the same implementation internally (well, kinda), and additionally the string values from these attributes will be throw into the JS engine anyway by creating anonymous functions from these strings (and that takes time, too ;)

Anyway, on the few occasions I actually did measure UI initialization in restartless add-ons (only the DOM stuff in JS) and it always came out taking something in the (lower) double-digit milliseconds range for any add-on with a reasonable amount of DOM and listeners (<100).

BTW:

I have also noticed startless addons that on occasions, the insertion itself was noticeable (ie the functionality, image, icon comes slightly after the window is loaded).

Yeah, some restartless add-ons eg load (toolbarbutton) images asynchronously, or delay (some) of their initialization to a later point (eg why populate the context menu before popupshowing ?). This can be a little bit less efficient (because it can cause redraws) or can be more efficient (because the browser can continue to execute other initialization code while eg images load in the background).

If restartless add-ons fail to initialize, then well, that is a bug. But I did mention that restartless add-ons are rather difficult to write already.

PS: Gecko Profiler and about:memory are your friends ;)