1372400 - Find out why loading.svg and burst.svg from bug 1352119 consume so much memory

Status: RESOLVED WONTFIX

(Core :: SVG, defect)

Description

[Mike Conley (:mconley) (:⚙️)]

In the spirit of proactivity, I'm pre-emptively examining the regressions that bug 1352119 is causing on Talos try builds, despite it not having been landed yet.

One of the things I've noticed are regressions on the "tp5o Main_RSS opt e10s" and "tp5o_webext Main_RSS opt e10s" measurements.

As far as I can tell, our Talos infrastructure figures out how much resident memory is being used by the parent process at the time of the tp5 test shutdown, and reports that result. With the new tab loading indicators in bug 1352119, we seem to have regressed those measurements.

Assuming the resident memory is being consumed by the new SVG images, I've been looking at how much those two new images take.

Here's a snippet from my about:memory on OS X with the patches in bug 1352119 applied:

├────3.54 MB (01.77%) -- images
│    ├──2.60 MB (01.31%) -- chrome
│    │  ├──2.50 MB (01.25%) -- vector/used
│    │  │  ├──0.66 MB (00.33%) -- image(840x4, chrome://browser/skin/tabbrowser/loading.svg)
│    │  │  │  ├──0.65 MB (00.33%) ── source
│    │  │  │  └──0.02 MB (00.01%) -- locked/surface(840x4)
│    │  │  │     ├──0.02 MB (00.01%) ── decoded-nonheap
│    │  │  │     └──0.00 MB (00.00%) ── decoded-heap
│    │  │  ├──0.43 MB (00.21%) -- image(0x0, chrome://browser/skin/tabbrowser/loading-burst.svg)
│    │  │  │  ├──0.39 MB (00.19%) -- locked/surface(317x318)
│    │  │  │  │  ├──0.39 MB (00.19%) ── decoded-nonheap
│    │  │  │  │  └──0.00 MB (00.00%) ── decoded-heap
│    │  │  │  └──0.04 MB (00.02%) ── source


Over half a meg each... seems excessive... why are these SVGs costing so much to store? That loading.svg, even at 840x40, assuming 4 bytes per pixel, that's only 13440 bytes... so where's this half-meg of "source" coming from? Is it SVG DOM-y stuff?

Comment 1

[Mike Conley (:mconley) (:⚙️)]

Any pointers here, jwatt?

Comment 2

[Timothy Nikkel (:tnikkel)]

(In reply to Mike Conley (:mconley) from comment #0)
> chrome://browser/skin/tabbrowser/loading-burst.svg)
> │    │  │  │  ├──0.39 MB (00.19%) -- locked/surface(317x318)
> │    │  │  │  │  ├──0.39 MB (00.19%) ── decoded-nonheap
> │    │  │  │  │  └──0.00 MB (00.00%) ── decoded-heap
> │    │  │  │  └──0.04 MB (00.02%) ── source

Is it expected to have a 317x318 rasterized copy of loading-burst.svg?

> Over half a meg each... seems excessive... why are these SVGs costing so
> much to store? That loading.svg, even at 840x40, assuming 4 bytes per pixel,
> that's only 13440 bytes... so where's this half-meg of "source" coming from?
> Is it SVG DOM-y stuff?

It's for the SVG document and everything associated with it, so the dom, the presshell, the frames, whatever else a document gets.

Comment 3

[Jonathan Watt [:jwatt]]

Yeah, loading.svg is a really complex SVG so it's not overly surprising 'source' shows up as 0.65 MB for it. (Whereas loading-burst.svg is very simple, corresponding to it "only" using 0.04 MB for 'source'.)

(In reply to Mike Conley (:mconley) from comment #1)
> Any pointers here, jwatt?

That depends on the answer to my question on loading.svg in bug 1352119 comment 26.

Comment 4

[Mike Conley (:mconley) (:⚙️)]

According to jmaher, the tp5 memory measurements aren't really worth paying attention to, and we should use the AWSY benchmarks instead.

As I originally opened this bug to investigate the tp5 memory measurements, with this information, I'm going to close this as WONTFIX. If it turns out that AWSY reports a memory use regression (for which I'll do some try pushes to try to confirm), I'll re-open this.