我理解安装自举扩展程序的便利性，但有一个问题一直困扰着我。
有没有表演＆amp;覆盖与资源之间的资源/内存使用比较引导扩展？
在叠加扩展中，许多工作，即XUL叠加等都是由应用程序（即Firefox）处理的。 在引导扩展中，所有上述工作都留给扩展开发人员，这通常涉及手动添加许多事件监听器和观察者以实现相同的目标（可能不像应用程序核心本地化）。
我注意到在某些窗口上无法启动的无启动插件。我也注意到了无用的插件，有时，插入本身是显而易见的（即窗口加载后功能，图像，图标稍微有点）。此外，所使用的均匀听众的类型并不均匀，并且变化很大。
我有一种唠叨的感觉，手动（而不是原生）添加菜单，上下文菜单，函数，字符串捆绑，首选项，本地化等，枚举窗口将使用更多资源（除了它的效率将极大地依赖于开发人员的技能）。
我期待着您的意见 ：）
答案 0 :(得分：3)
加载项的执行方式主要取决于实际的实现（加载项的作用和方式）以及它保留的数据。因此，您无法仅比较叠加与无重启加载项的性能。
我将叠加的加载项转换为后续运行效果更好的无加载项，因为我在此过程中优化了一些内容。当然，在其他情况下，情况恰恰相反。
内存消耗取决于附加组件的功能，包括。它创建了多少个事件监听器。除非你创建成千上万的事件监听器（也就是闭包中的伪泄漏），否则这些监听器消耗的内存通常可以忽略不计：内存会告诉你。你可以拥有内存饥饿的覆盖附件和轻量级无重启附加组件，反之亦然。
您的权利很大程度上取决于开发人员的技能，即实施和数据结构设计的质量，这些设计通常与所述技能直接相关。
overlay，style）。这些细节也是更高级别的抽象，并且需要付出代价。这有点像将C（无重启）与Java（覆盖）与Ruby（SDK）进行比较。人们喜欢Ruby的便利，但正确的Java代码很容易超越它。然后，Java通常会胜过由新手开发人员编写的等效C程序（也是那些新手开发人员更有可能在整个地方泄漏内存;），但是由熟练的开发人员编写的C程序可能胜过Java。
您在此处提出的问题基本上表示premature optimization。而是根据您的技能水平编码，测量然后进行优化。
一旦您注意到您的插件消耗大量内存或运行缓慢，则测量和/或调试原因。或者只是积极主动地衡量。重点是：度量。
如果您的插件不是行为不当，请告诉作者，或file a tech evangelism bug是否真的不好。
由于您询问DOM操作/叠加层，addEventListener与＃34;本地＆＃34;：
addEventListener通常非常快。事实上，叠加＆＃34;事件＆＃34;听众，（那些讨厌的oncommand / onclick / onwhatever属性），在内部使用相同的实现（好吧，有点），另外这些属性的字符串值将被扔进JS无论如何，通过从这些字符串创建匿名函数（这也需要时间;）无论如何，在少数情况下，我实际上测量了无重启加载项中的UI初始化（只有JS中的DOM内容），并且它总是出现在任何附加组件的（较低的）两位数毫秒范围内。使用合理数量的DOM和侦听器（＆lt; 100）。
顺便说一句：
我也注意到了无用的插件，有时插入本身很明显（即窗口加载后功能，图像，图标略有出现）。
是的，一些无重启的插件，例如异步加载（toolbarbutton）图像，或者将它们的初始化延迟（某些）到稍后的点（例如，为什么要在popupshowing之前填充上下文菜单？）。这可能效率稍低（因为它可能导致重绘）或者可能更有效（因为浏览器可以继续执行其他初始化代码，例如图像在后台加载）。
如果无重启的附加组件无法初始化，那么这就是一个错误。但我确实提到重新启动的附加组件已经很难写了。
PS：Gecko Profiler和about:memory是你的朋友;）