about:processes doesn't show memory usage per tab or split extensions
Categories
(Toolkit :: Performance Monitoring, defect)
Tracking
()
People
(Reporter: pzz, Unassigned)
References
(Regression)
Details
(Keywords: regression)
User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:109.0) Gecko/20100101 Firefox/116.0
Steps to reproduce:
tried to see which tab is sucking CPU
Actual results:
about:performance is gone
Expected results:
about:performance always answered that question directly
about:processes heads off a goose chase that might answer the question quite indirectly. a sad compromise.
|
||
Comment 2•11 months ago
|
||
The Bugbug bot thinks this bug should belong to the 'Core::Widget: Gtk' component, and is moving the bug to that component. Please correct in case you think the bot is wrong.
|
||
Updated•11 months ago
|
|
|
||
Comment 3•11 months ago
|
||
:florian, since you are the author of the regressor, bug 1836191, could you take a look? Also, could you set the severity field?
For more information, please visit BugBot documentation.
after working with about:processes a bit more, when i sort by CPU, that works passably well. it's when i sorted about:performance by Memory, that's what's not similarly available in about:processes.
|
||
Comment 5•11 months ago
|
||
(In reply to gregrwm from comment #4)
it's when i sorted about:performance by Memory, that's what's not similarly available in about:processes.
about:processes can also be sorted by Memory.
About performance sorts memory usage by tab. About processes leaves it to the user to work out which tab is consuming what amount of memory. Not nearly the same.
Doesn't work for me. (Unless that's changed in the last 4days. i'm away, on mobile, for 2weeks.)
|
||
Comment 7•10 months ago
|
||
about:processes has a few significant regressions compared to about:performance (as of FF 117.0a1):
- Extensions are grouped into one process without possibility to differentiate between them
- Memory usage is shown for processes, not for tabs.
The latter has more significant impact in corporate use, as it's quite common in corporate world to have vastly different services running on subdomains of the same domain (and thus using the same processes). I.e. you can have gitlab.corpdomain, slack.corpdomain and jira.corpdomain tabs running in the same process.
And in my experience new UI is far less clear and prompts users to do things they may not want/need at all: closing sets of tabs and calling profiler
|
||
Updated•10 months ago
|
|
||
Comment 8•10 months ago
|
||
Florian, can you help triaging this? I'm guessing we'd want to have separate bugs for the two missing features, but I'm not sure how feasible it is to provide either/both given the current architecture (and/or if doing so should depend on architecture changes e.g. process-per-extension).
|
|
||
Comment 9•10 months ago
|
||
(In reply to :Gijs (he/him) from comment #8)
I'm not sure how feasible it is to provide either/both given the current architecture
It's indeed not possible. The thing that makes about:processes more reliable than about:performance is that it works all in the parent process, and uses OS APIs. about:performance relied on sending IPCs to all child processes and getting a reply within a reasonable amount of time (which meant information for tabs from unresponsive processes was not shown in about:performance, despite being often the most interesting to kill).
I don't think we would want to do the changes to make it possible to have information at a lower granularity than the process level, as we would again depend on processes replying to IPCs (and would also have to wake-up all processes, causing significant overhead).
One constraint of about:performance/about:processes, is that we need to be able to update the data within a short amount of time (less than 2s). If the goal of someone is to figure out which tab is using too much memory within a given process, about:memory is a good alternative, but takes many seconds to display.
For developers, profiling is a useful way to figure out which tab is using too much CPU (and often which tab is using too much memory).
So... I would say this is WONTFIX.
|
Reporter | |
Comment 10•10 months ago
|
||
about:memory as is doesn't reveal memory usage per tab, or if it does it's buried in heaps of data.
What's needed now is to undo the regression, restore the jettisoned PER TAB memory usage report, sorted by memory usage, without waking up all processes! This could be implemented simply by whenever any process changes its memory usage, report its PER TAB memory usage to the appropriate, probably master process.
Description
•