4 ms·
If they cared and their slowdowns were simply related to addons, they could always sample the overhead of said addons and show a warning. My moderate use of add
by adra 4y ago
If they cared and their slowdowns were simply related to addons, they could always sample the overhead of said addons and show a warning. My moderate use of addons in FF didn't feel too aggressive, but then again I'm not in the clique with dozens of open windows. There were times of fast/slowness in FF. It was never bad enough to chase me off the platform, but to say the slow ess was simply saddled on addons is probably disingenuous.
- Karellen 4y agoIt's not that the addons were slow. It's that the architecture in Firefox that was needed to support the addons was slow - even if there were no addons in use.
- spiffytech 4y agoThe slowness wasn't caused (just) by slow addons. As I remember it, Firefox was unable to move to a multi-process architecture as long as old extensions were supported.
- mook 4y agoMy recollection was that they had some multi-process things, though the problem was that they had to keep breaking extensions as they added more and more. I believe multi-process NPAPI plugins was somewhere around 3.6 or 4? (Of course, 4 took forever to ship too… that was great for extensions though, because it meant no API breakage during that time.)
- adjav 4y agoIt's not that the add-ons were slow, it's that the architecture built to support those add-ons made the browser as a whole inherently slow. Everything was quite siloed, and required a series of dynamic dispatches to accomplish anything. This allowed extensions to easily change lots of core functionality, but also meant that the entire Firefox codebase had become a public API, and practically any change made would break something.
- deleted 4y ago[deleted]