Closed
Bug 969114
Opened 11 years ago
Closed 11 years ago
MediaCacheStream wastes about 10% memory in allocation slop
Categories
(Core :: Audio/Video, defect, P1)
Tracking
()
People
(Reporter: bkelly, Assigned: bkelly)
References
Details
(Keywords: memory-footprint, perf, Whiteboard: [c=memory p= s= u=tarako] [MemShrink])
Attachments
(1 file)
(deleted),
patch
|
cpearce
:
review+
|
Details | Diff | Splinter Review |
DMD run on the poppit app on b2g v1.3 showed:
Unreported: 108 blocks in stack trace record 1 of 424
3,981,312 bytes (3,579,552 requested / 401,760 slop)
8.08% of the heap (8.08% cumulative); 20.07% of unreported (20.07% cumulative)
Allocated at
replace_malloc /srv/mozilla-b2g28_v1_3/memory/replace/dmd/DMD.cpp:1247 (0x4006e74e libdmd.so+0x374e)
malloc /srv/mozilla-b2g28_v1_3/memory/build/replace_malloc.c:152 (0x400feeba libmozglue.so+0x23eba)
moz_xmalloc /srv/mozilla-b2g28_v1_3/memory/mozalloc/mozalloc.cpp:53 (0x4182aefe libxul.so+0x132aefe)
mozilla::MediaResource::Create(mozilla::MediaDecoder*, nsIChannel*) /srv/mozilla-b2g28_v1_3/content/media/MediaResource.>
mozilla::dom::HTMLMediaElement::InitializeDecoderForChannel(nsIChannel*, nsIStreamListener**) /srv/mozilla-b2g28_v1_3/co>
mozilla::dom::HTMLMediaElement::MediaLoadListener::OnStartRequest(nsIRequest*, nsISupports*) /srv/mozilla-b2g28_v1_3/obj>
nsJARChannel::OnStartRequest(nsIRequest*, nsISupports*) /srv/mozilla-b2g28_v1_3/modules/libjar/nsJARChannel.cpp:966 (0x4>
nsInputStreamPump::OnStateStart() /srv/mozilla-b2g28_v1_3/netwerk/base/src/nsInputStreamPump.cpp:517 (0x40895d2e libxul.>
nsInputStreamPump::OnInputStreamReady(nsIAsyncInputStream*) /srv/mozilla-b2g28_v1_3/netwerk/base/src/nsInputStreamPump.c>
This shows that MediaCacheStream is wasting about 10% of the memory it actually requested in allocation slop.
This is due to the 32KB MediaCacheStream::mPartialBlockBuffer member array. While it fits exactly in a power-of-2 allocation, the remaining member variables push it over into the next allocation size bigger.
This could be solved by allocating mPartialBlockBuffer separately on the heap. This would be a minor win, but might be worth it given potential media use in games and other apps on b2g
Assignee | ||
Comment 1•11 years ago
|
||
This moves the mPartialBlockBuffer to a separate heap allocation to avoid slop.
Attachment #8373155 -
Flags: review?(cpearce)
Updated•11 years ago
|
Attachment #8373155 -
Flags: review?(cpearce) → review+
Assignee | ||
Comment 2•11 years ago
|
||
Modest memory gains, but nom for 1.3t? since this is a low risk patch.
blocking-b2g: --- → 1.3T?
Assignee | ||
Comment 3•11 years ago
|
||
Pushed to b2g-inbound with messed up and then corrected commit log again:
remote: https://hg.mozilla.org/integration/b2g-inbound/rev/76e72417a9d7
remote: https://hg.mozilla.org/integration/b2g-inbound/rev/b3150ee1da4d
remote: https://hg.mozilla.org/integration/b2g-inbound/rev/b986786cf7dd
Sorry for the botched land again!
Comment 4•11 years ago
|
||
Status: ASSIGNED → RESOLVED
Closed: 11 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla30
Assignee | ||
Updated•11 years ago
|
status-b2g-v1.3T:
--- → affected
status-b2g-v1.4:
--- → fixed
Updated•11 years ago
|
Priority: -- → P1
Whiteboard: [c=memory p= s= u=][MemShrink] → [c=memory p= s= u=tarako] [MemShrink]
Comment 6•11 years ago
|
||
Updated•8 years ago
|
You need to log in
before you can comment on or make changes to this bug.
Description
•