“It’s safe to say that the people who volunteered to “shape” the initiative want it dead and buried. Of the 52 responses at the time of writing, all rejected the idea and asked Mozilla to stop shoving AI features into Firefox.”
“It’s safe to say that the people who volunteered to “shape” the initiative want it dead and buried. Of the 52 responses at the time of writing, all rejected the idea and asked Mozilla to stop shoving AI features into Firefox.”
What does being opt-in or opt-out have to do with resource consumption? It will still consume resources even if you’re not using it. It might even reserve memory while inactive for faster startup by default.
Even if you completely disable it, just having it built into the default binary already consumes resources.
A disabled service will not consume any RAM. People just look for excuses to hate on it because it has AI in the name.
First it was that it would consume 4GB of RAM in the background. Then that it might reserve the memory just in case. Now the issue is that even if it didn’t, it would make the binary larger lol.
I sure hope you also complain about all the disabled drivers that ship with your Linux kernel.
A larger binary maps 1:1 to a larger memory footprint in most cases.
Disabled code is still part of the process address space, which is pre-allocated on startup for every instance of the Firefox process that’s launched[1]. This affects both startup time and memory usage, and during startup, it depends on disk i/o speed as well.
AI is not a trivial feature. It will need a lot of dependencies, each library will also be loaded to the address space on startup, and will recursively load its own dependencies into memory. Factor these as well.
Now, how many subprocesses does Firefox launch during a typical session?
The Firefox multi-process model launches a minimum of 4 background host processes by default last I checked (Quantum), maybe more for extensions and other things, and a dedicated GPU rendering process if DMA-BUF is enabled if I remember correctly. (Can someone verify?)
Multiply that process count by the size of the new code and dependencies they pull and you’ll get a not-so-insignificant number, especially considering the complexity of the feature in question.
And aside from the aforementioned issues: a disabled service at runtime can still mean thousands of CPU instructions wasted everywhere checking whether it’s enabled or not. Depends on how tightly integrated it is. [2]
I certainly would if they all got loaded every time my system started up.
[1] Unless the code is linked dynamically and loaded on demand at runtime via
dlopenor the equivalent on Windows. I won’t claim extreme familiarity with the codebase, but I’ve worked with Firefox sources in the past while testing SpiderMonkey in an old project, and from my experience, that’s not the typical method used in the code and is only used to load some system and third-party libraries (such multimedia codecs, etc) that aren’t referenced at link-time.[2] if it’s not very tightly integrated then it shouldn’t be in the main binary to begin with. If it’s as useful as they portray then it will have checks sprinkled everywhere.