[azakai]

Both features have near-negligible overhead if you don't use them. But having them in the product makes them accessible to the wide userbase, many of whom don't know what addons are or how to install them.

Therefore it seems reasonable to add them to Firefox.

[weaksauce]

I'd much prefer them to improve the memory and performance reporting features over adding some features that goes against their core values. right now I have a firefox that uses tons of ram and slows down to a halt very frequently but there are no decent tools to diagnose what addin/plugin/webpage/bug might be causing trouble. it's very, very frustrating.

edit: I am talking about multiple gigs of memory for firefox and multiple gigs of memory in the kernel task allocated for who knows what. stop firefox and it lowers the kernel memory to a reasonable level and (obviously) removes the memory usage of firefox.

[derefr]

I see this argument all the time in the form of "why are they working on the UI instead of the backend?" Well, because UI engineers and backend engineers are different people and don't share one-another's competencies, is why. The people who are adding these things probably don't know how to improve Firefox's performance. They're probably networked-multimedia engineers scratching their own itch.

(And it's not like Firefox's performance has any low-hanging fruit left; there have been years of performance improvements already, and only someone versed in those would know how to take them further.)

[weaksauce]

The ui for about:memory is bad and not very useful in tracking down where the memory is going or leaking. That's something the ui engineers can do to help Firefox with this.

[dblohm7]

It's useful to Gecko engineers, ie. the people who actually have to fix it.

[azakai]

There are a lot of people working on performance - it's just less press-worthy than new features, so less noticed I guess. But bugs do exist, of course. Do you see anything odd in about:memory that can help diagnose your specific issue?

[Drdrdrq]

Sorry to say that, but about:memory is useless to me. When memory runs low and system starts swapping (slowing down to a crawl) my first priority is to get computer running again, so I have to close firefox. That helps, but about:memory no longer has the data that would lead to the culprit.

Even if I could look at histotic data, the UI of about:memory is just plain awful. Charts anyone? My main question is how the consumption of memory for each tab is changing through time and I haven't found a nice way to see that yet.

Also, browser should protect me from pages which use too many resources. Why should some random page be able to stop my computer from working? I am seriously considering running firefox inside docker container just so I can limit its resources.

Note that I am a huge fan of ff and use it everywhere, but this has been a sore point for me for ages.

[weaksauce]

I agree that it's a tough problem and they have smart engineers working on it. The about:memory anonymizer makes the output useless to the engineers looking at the bug. A better way would be to anonymize it but still keep it identifiable if you have the key. Say make each page a uuid or something so that the engineer can say, "search for this uuid in your in anonymous report and that's leaking memory"

It seems that the tools to diagnose what has been the most criticized series of bugs in Firefox are still lacking. Ideally it should list the plugins used and the memory of each along with a way to identify the heavy pages etc.