Closed
Bug 898526
Opened 12 years ago
Closed 12 years ago
pid isn't shown in a diff
Categories
(Toolkit :: about:memory, defect)
Toolkit
about:memory
Tracking
()
RESOLVED
WONTFIX
People
(Reporter: mccr8, Unassigned)
Details
Loading B2G memory reports A and B (from b2g18), they show "Main Process (pid 140)", but when I diff A and B, it shows "(Preallocated app) (pid NNN)".
| Reporter | ||
Comment 1•12 years ago
|
||
The latter part should be "Main Process (pid NNN)".
Comment 2•12 years ago
|
||
The pids are deliberately obfuscated, because the diff matching is based on paths and we want paths that differ only in the pid to be considered equal. Otherwise if you do two runs in a row where the pids differ, you can't diff them.
So, this is a feature, not a bug, unless I've misunderstood what you're saying.
Is this causing problems in some way? I guess if you have multiple copies of the same app open it might cause their results to be conflated?
We should show the pid for the main process at least if it hasn't changed.
| Reporter | ||
Comment 4•12 years ago
|
||
jlebar was also suggesting we could even show the pids for both of the processes separately, if they are different. But I'd be happy enough if it just showed the PID when it matched.
My specific case was that I'd loaded up an about:memory diff, and I was trying to figure out what the PID was for the main process, so I ended up having to load just one of the about:memory reports individually so I could figure out which DMD report to load in a text editor.
Comment 5•12 years ago
|
||
Currently the implementation just stuffs all the paths from the first report in a hash table (i.e. a JS object) and then iterates over the paths from the second report and it can do hash table lookups (using paths as keys) to find matches.
> We should show the pid for the main process at least if it hasn't
> changed.
That would require pre-scanning all the paths and looking for pids and deciding if they match not to obfuscate them. It would work if you are comparing two measurements from the same run (i.e. looking for slow leaks), but wouldn't do anything if comparing two measurements from different runs, which is also a common scenario.
> jlebar was also suggesting we could even show the pids for both of the
> processes separately, if they are different.
To do that, the lookup would have to change so that paths have different pids but are otherwise equal would be considered equal. I.e. instead of vanilla JS objects it'd have to use a hash table with a custom pid-ignoring matcher. Possible, but it would complicate the implementation quite a bit. The pre-scanning would be easier.
When I've looked at diffs, I usually end up with three windows anyway: one for each of the original reports, and one for the diff.
| Reporter | ||
Updated•12 years ago
|
Status: NEW → RESOLVED
Closed: 12 years ago
Resolution: --- → WONTFIX
You need to log in
before you can comment on or make changes to this bug.
Description
•