Closed Bug 672732 Opened 13 years ago Closed 13 years ago

Don't report per-compartment measurements that have zero bytes

Categories

(Core :: XPConnect, defect)

x86_64
Linux
defect
Not set
normal

Tracking

()

RESOLVED FIXED
mozilla8

People

(Reporter: n.nethercote, Assigned: n.nethercote)

References

Details

(Whiteboard: [MemShrink])

Attachments

(1 file)

Here's an example compartment report: ├────3,940,269 B (01.07%) -- compartment(https://blog.mozilla.com/nnethercote/wp-login.php) │ │ ├──2,736,128 B (00.74%) -- gc-heap │ │ │ ├──1,330,152 B (00.36%) -- arena-unused │ │ │ ├────781,760 B (00.21%) -- shapes │ │ │ ├────557,888 B (00.15%) -- objects │ │ │ ├─────34,616 B (00.01%) -- arena-padding │ │ │ ├─────16,032 B (00.00%) -- arena-headers │ │ │ ├─────15,680 B (00.00%) -- strings │ │ │ └──────────0 B (00.00%) -- xml │ │ ├────655,360 B (00.18%) -- mjit-code │ │ ├────487,941 B (00.13%) -- scripts │ │ ├─────47,344 B (00.01%) -- object-slots │ │ ├─────13,496 B (00.00%) -- string-chars │ │ ├──────────0 B (00.00%) -- mjit-data │ │ ├──────────0 B (00.00%) -- tjit-code │ │ └──────────0 B (00.00%) -- tjit-data │ │ ├──0 B (00.00%) -- allocators-main │ │ └──0 B (00.00%) -- allocators-reserve Six entries are zero. Printing them all is a bit pointless, especially since we can have lots of compartments. I propose not reporting the zero entries to save space. A side-benefit: it'll help us forget that E4X support exists :P
Summary: Don't print sub-compartment entries that have zero bytes → Don't report per-compartment measurements that have zero bytes
Attached patch patch (deleted) — Splinter Review
Simple patch.
Attachment #547323 - Flags: review?(gal)
Attachment #547323 - Flags: review?(gal) → review+
Whiteboard: [MemShrink] → [MemShrink][inbound]
Status: NEW → RESOLVED
Closed: 13 years ago
Resolution: --- → FIXED
Whiteboard: [MemShrink][inbound] → [MemShrink]
Target Milestone: --- → mozilla8
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: