1KB data url SVG allocates ~17KB in core/html/parser |
|||||||||||||
Issue descriptionInvestigating the memory of SVG images I found that a 1KB data url SVG image allocates ~17KB in core/html/parser. My testcase is here with 1000 unique 1KB SVG data uri images: https://output.jsbin.com/bijoyaf/quiet Using --enable-heap-profiling and about:tracing with memory-infra enabled, I found this page allocates 20.8MB (malloc) of which the parser is 17.0MB. I found this malloc does not occur if the svg data is all inlined on an html page. Kouhei, would you be able to look into this? This is important for low-memory android devices.
,
Jul 12 2017
Interesting find! I'll take a brief look today or tomorrow to get a rough estimate on what we can do.
,
Jul 12 2017
,
Jul 12 2017
@pdr: do you mean that when inlining the SVG it avoids all 17MB?
,
Jul 12 2017
Inlining the SVG drops the allocations to near zero. Possibly SVGImage is leaving around HTMLParser data?
,
Jul 12 2017
,
Jul 13 2017
This path is actually triggering XML parser not HTML parser. I'll follow up details shortly.
,
Jul 13 2017
,
Jul 17 2017
Were you able to make any more progress on this?
,
Jul 18 2017
No. I'm keeping the doc up to date. Yesterday was a public holiday in Japan and code search seems still missing Xrefs. I plan to work on this until I have a good explanation of the stack trace graph (esp for ProxyResolverFactory). I'd appreciate your help if you want to move this faster. For example, I think we can distribute work figuring out mallocs involved in "creating a frame" and "libxml parsing svg XML".
,
Jul 20 2017
tasak@ is currently investigating the unknown 9MB. Please see the doc for details
,
Jul 24 2017
,
Jul 24 2017
I've just finished investigating "9300KiB not captured by the allocator shim" in the document. The most of the allocation is required by tracing. e.g. tcmalloc's PageHeap::stats_.unmapped_bytes += 13,950,976 at stacktrace: ShimRealloc at base/allocator/allocator_shim.cc:218 (inlined by) __libc_realloc at base/allocator/allocator_shim_override_glibc_weak_symbols.h:86 Resize at base/pickle.cc:381 ClaimUninitializedBytesInternal at base/pickle.cc:463 (inlined by) WriteBytesCommon at base/pickle.cc:477 (inlined by) WriteBytes at base/pickle.cc:349 WriteKeyNameAsRawPtr at base/trace_event/trace_event_argument.cc:49 (inlined by) BeginArray at base/trace_event/trace_event_argument.cc:183 c.f. https://docs.google.com/a/google.com/spreadsheets/d/1Z4xu8X2jGFYq9phxPahse3wZKmd0zuHuqge5h6vVE6U/edit?usp=sharing (This spreadsheet was created by dumping data when changing unmapped_size of PageHeap::stats_. The data is [function_name, delta of unmapped_size, unmapped_size, thread_id, stacktrace].) So malloc usage will be reduced after finishing tracing.
,
Mar 16 2018
Withouot this tracing overhead, how much overhead still remains?
,
Mar 19 2018
I obtained trace.json again. I think, without this tracing overhead, "tracing" column says remaining tracing overhead. i.e. 0.6MiB (renderer) This issue will be fixed by new native sampling profiler. c.f. crbug.com/803276
,
Aug 2
,
Sep 10
Closing WontFix based on comment #19. |
|||||||||||||
►
Sign in to add a comment |
|||||||||||||
Comment 1 by pdr@chromium.org
, Jul 12 2017