Closed Bug 1009097 Opened 11 years ago Closed 11 years ago

include image urls and sizes in about:memory

Categories

(Toolkit :: about:memory, defect)

Product:
Toolkit
Component:
about:memory
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

()

Status:
RESOLVED FIXED
Milestone:
mozilla32

People

(Reporter: bkelly, Assigned: n.nethercote)

References

Details

(Whiteboard: [MemShrink:P1])

Attachments

(2 files, 1 obsolete file)

instrument.imgLoader.cpp.patch
3.72 KB, patch
Details | Diff | Splinter Review
Report notable images individually
19.84 KB, patch
jwatt
: review+
Details | Diff | Splinter Review
In bug 1001455 attachment 8412649 [details] Vivien dumped the memory usage of each image in the parent process sorted by size. This looks like a useful tool for diagnosing problems. We might want to include this in about:memory. Vivien says he has a patch he can attach here.
Is this a dupe of bug 921300?
(In reply to Nicholas Nethercote [:njn] from comment #1) > Is this a dupe of bug 921300? I guess it could be depending on how bug 921300 is implemented. This bug is more about giving the details of the images individually, while bug 921300 seems more about grouping the image data per tab. For example, Vivien's tool generates this kind of output showing size in KB and then the source of the image: 628 Name (used): app://system.gaiamobile.org/style/lockscreen/images/mask.png (raw: 28672) (u heap: 80) (u non-heap: 614400) 604 Name (used): app://system.gaiamobile.org/shared/style/value_selector/images/ui/gradient.png (raw: 4096) (u heap: 80) (u non-heap: 614400) 604 Name (used): app://system.gaiamobile.org/shared/style/confirm/images/ui/gradient.png (raw: 4096) (u heap: 80) (u non-heap: 614400) 604 Name (used): app://communications.gaiamobile.org/shared/style/confirm/images/ui/gradient.png (raw: 4096) (u heap: 80) (u non-heap: 614400) 604 Name (used): app://callscreen.gaiamobile.org/shared/style/action_menu/images/ui/gradient.png (raw: 4096) (u heap: 80) (u non-heap: 614400) 388 Name (used): blob:b866d1cc-c805-44a5-833f-21fbad6de108 (raw: 90112) (u heap: 80) (u non-heap: 307200) 388 Name (used): blob:96c4b889-622b-4836-badd-93b41d48cc7c (raw: 90112) (u heap: 80) (u non-heap: 307200) 128 Name (used): app://system.gaiamobile.org/style/statusbar/images/icons.png (raw: 8192) (u heap: 80) (u non-heap: 122880)
Ben, so you'd like to see this per-process outside of explicit? Maybe something like: other image-info |-- app://system.gaiamobile.org/style/lockscreen/images/mask.png | |-- raw | |-- heap | |-- non-heap |-- blob:b866d1cc-c805-44a5-833f-21fbad6de108 Also what do "raw," "u heap," and "u non-heap" actually mean? Vivien can you attach your patch?
Flags: needinfo?(21)
Yea, I think that would be really helpful. I have no idea what raw/heap/non-heap means. I would ok with just a total size. I guess we would have to throttle how many image resources we show since some pages may have a ton of images.
Whiteboard: [MemShrink] → [MemShrink:P1]
> I guess we would have to throttle how many image resources we show since > some pages may have a ton of images. The JS memory reporter does this kind of thing. You can do things like aggregate all entries less than a certain size (either absolute size, such as 8 KiB, or relative size, such as 1% of the total).
I believe raw = compressed size (the size of the image file), u being short for used, and used being a shorthand for images that have a non-zero lock count. So u heap is the heap memory for the decoded size of images that have non-zero lock count. Similar for non-heap.
The patch is really dumb for now. But it's really useful to identify which images is taking the memory in the system app.
Flags: needinfo?(21)
I can take the patch and move its function into the existing reporter.
Assignee: nobody → n.nethercote
This patch implements per-image reporting for raster images, and tweaks the reporting of vector image documents. jwatt, I'm asking you for review since you were just in this part of the code recently, and I'm modifying code that you wrote. Feel free to ask an ImageLib peer for additional review if you're not comfortable reviewing this entirely by yourself. Changes of note are as follows. - Single images smaller than 16 KiB -- both raster and vector -- are now aggregated into "non-notable" reports with other similar images of the same kind. This avoid bloating about:memory too much. - With images being reported individually, you can't get aggregate values easily. So I've replicated this in a new "images" tree in the other measurements section. (Example below.) - Vector image URIs are now written "document(<uri>)", which makes them more like other memory reporters. Previously they were written "(<uri>)". - The descriptions are shorter. This continues a trend I've been following in other memory reporters -- starting every description with "Memory used by/for..." isn't useful. - I've used templates a bit because there's plenty of overlap between the raster and vector image reporting. Here's example output from the "Explicit Allocations" tree: > ├────3,796,312 B (02.13%) -- images > │ ├──2,793,952 B (01.57%) -- content > │ │ ├──2,793,952 B (01.57%) -- raster > │ │ │ ├──2,424,832 B (01.36%) -- used > │ │ │ │ ├────507,904 B (00.29%) -- image(file:///home/njn/.cache/mozilla/firefox/q9ak3gjn.dev/thumbnails/2528d775931078ef3757296975d3a809.png) > │ │ │ │ │ ├──507,904 B (00.29%) ── raw > │ │ │ │ │ ├────────0 B (00.00%) ── uncompressed-heap > │ │ │ │ │ └────────0 B (00.00%) ── uncompressed-nonheap > │ │ │ │ ├────200,704 B (00.11%) ++ image(file:///home/njn/.cache/mozilla/firefox/q9ak3gjn.dev/thumbnails/44aab9349e12f5f06a8a6aab951311aa.png) > │ │ │ │ ├────163,840 B (00.09%) ++ image(file:///home/njn/.cache/mozilla/firefox/q9ak3gjn.dev/thumbnails/ca1e6357399774951eed4628d69eb84b.png) > │ │ │ │ ├────151,552 B (00.09%) ++ image(file:///home/njn/.cache/mozilla/firefox/q9ak3gjn.dev/thumbnails/9e561e9761e9db9cf028e74652cf52d0.png) > │ │ │ │ ├────135,168 B (00.08%) ++ image(<non-notable images>) > │ │ │ │ ├────118,784 B (00.07%) ++ image(http://cdn.arstechnica.net/wp-content/uploads/2014/05/netflix-hardware-300x150.png) > ... > │ │ │ │ ├─────16,384 B (00.01%) ++ image(http://cdn.arstechnica.net/wp-content/uploads/2014/05/iranrq170-300x150.jpg) > │ │ │ │ └─────16,384 B (00.01%) ++ image(http://cdn.arstechnica.net/wp-content/uploads/2014/05/social-security-hack-300x100.jpg) > │ │ │ └────369,120 B (00.21%) -- unused > │ │ │ ├──152,032 B (00.09%) ++ image(<non-notable images>) > │ │ │ ├───61,440 B (00.03%) ++ image(http://reddpics.com/assets/extra/trish.jpg) > │ │ │ ├───45,056 B (00.03%) ++ image(http://reddpics.com/assets/_image/25k4ul.jpg) > │ │ │ ├───24,576 B (00.01%) ++ image(http://reddpics.com/assets/_image/25kw7h.jpg) > │ │ │ ├───20,480 B (00.01%) ++ image(http://reddpics.com/assets/_image/25jmsb.jpg) > │ │ │ ├───16,384 B (00.01%) ++ image(http://reddpics.com/assets/_image/25jfeu.jpeg) > │ │ │ ├───16,384 B (00.01%) ++ image(http://reddpics.com/assets/_image/25jymr.jpg) > │ │ │ ├───16,384 B (00.01%) ++ image(http://reddpics.com/assets/_image/25kzur.jpg) > │ │ │ └───16,384 B (00.01%) ++ image(http://reddpics.com/assets/_image/25l9o1.jpg) > │ │ └──────────0 B (00.00%) -- vector > │ │ ├──0 B (00.00%) ── unused/documents/document(<non-notable images>) > │ │ └──0 B (00.00%) ── used/documents/document(<non-notable images>) > │ └──1,002,360 B (00.56%) -- chrome > │ ├────959,192 B (00.54%) -- vector > │ │ ├──959,192 B (00.54%) -- used/documents > │ │ │ ├──253,600 B (00.14%) ── document(chrome://global/skin/icons/close.svg) > │ │ │ ├──246,904 B (00.14%) ── document(chrome://browser/skin/tabbrowser/tab-selected-end.svg) > │ │ │ ├──246,904 B (00.14%) ── document(chrome://browser/skin/tabbrowser/tab-selected-start.svg) > │ │ │ ├──211,784 B (00.12%) ── document(chrome://global/skin/icons/panelarrow-vertical.svg) > │ │ │ └────────0 B (00.00%) ── document(<non-notable images>) > │ │ └────────0 B (00.00%) ── unused/documents/document(<non-notable images>) > │ └─────43,168 B (00.02%) -- raster > │ ├──43,168 B (00.02%) -- used > │ │ ├──21,584 B (00.01%) ++ image(chrome://browser/skin/tabbrowser/connecting.png) > │ │ ├──21,584 B (00.01%) ++ image(chrome://browser/skin/tabbrowser/loading.png) > │ │ └───────0 B (00.00%) ++ image(<non-notable images>) > │ └───────0 B (00.00%) ++ unused/image(<non-notable images>) And here are the corresponding summary numbers from the "Other Measurements" section: > 3,796,312 B (100.0%) -- images > ├──2,793,952 B (73.60%) -- content > │ ├──2,793,952 B (73.60%) -- raster > │ │ ├──2,424,832 B (63.87%) -- used > │ │ │ ├──2,424,832 B (63.87%) ── raw > │ │ │ ├──────────0 B (00.00%) ── uncompressed-heap > │ │ │ └──────────0 B (00.00%) ── uncompressed-nonheap > │ │ └────369,120 B (09.72%) -- unused > │ │ ├──369,120 B (09.72%) ── raw > │ │ ├────────0 B (00.00%) ── uncompressed-heap > │ │ └────────0 B (00.00%) ── uncompressed-nonheap > │ └──────────0 B (00.00%) -- vector > │ ├──0 B (00.00%) ── unused/documents/ > │ └──0 B (00.00%) ── used/documents/ > └──1,002,360 B (26.40%) -- chrome > ├────959,192 B (25.27%) -- vector > │ ├──959,192 B (25.27%) ── used/documents/ > │ └────────0 B (00.00%) ── unused/documents/ > └─────43,168 B (01.14%) -- raster > ├──43,168 B (01.14%) -- used > │ ├──43,168 B (01.14%) ── uncompressed-heap > │ ├───────0 B (00.00%) ── raw > │ └───────0 B (00.00%) ── uncompressed-nonheap > └───────0 B (00.00%) -- unused > ├──0 B (00.00%) ── raw > ├──0 B (00.00%) ── uncompressed-heap > └──0 B (00.00%) ── uncompressed-nonheap
Attachment #8422939 - Flags: review?(jwatt)
One thing I forgot to implement: I should truncate image locations that exceed a certain length. Because they can be data URIs, which can be enormous, and having the full data URI in the memory report isn't useful.
Two minor tweaks: - Now truncating long URIs at 256 chars. - Not reporting zero-sized measurements.
Attachment #8423478 - Flags: review?(jwatt)
Attachment #8422939 - Attachment is obsolete: true
Attachment #8422939 - Flags: review?(jwatt)
jwatt: review ping!
Comment on attachment 8423478 [details] [diff] [review] Report notable images individually Sorry for the delay here.
Attachment #8423478 - Flags: review?(jwatt) → review+
Whoops, I used Vivien's patch as a starting point, and discarded all of it, but then forgot to change the author on that patch. Oh well.
https://hg.mozilla.org/mozilla-central/rev/9c9833f16a62
Status: NEW → RESOLVED
Closed: 11 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla32
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: