Gaia developers are choosing not to use SVG for icons due to greater load times and memory footprint. Anthony Ricaud wrote about this here: https://groups.google.com/d/topic/mozilla.dev.gaia/Qpg8tQBD_e0/discussion We should see what we can do to make SVG more competitive with PNGs for icons. I've filed this as a meta bug for tracking specific improvements we can make.

tl;dr; > dumps for a file with 200 PNGs, 200 SVGs or 200 paragraphs with the > letter a. > > Load times: SVG: ~4500ms PNG: ~1600ms Text: ~850ms > > Memory when the app is foreground: SVG: 41.24MB PNG: 10.41MB Text: > 8.15MB > > Memory when the app is in the background: SVG: 40.54MB PNG: 9.06MB > Text: 8.07MB

Elapsed time and memory use look way out of whack for SVG here, especially for this simple case.

It may well be most efficient to use PNG bitmaps for these icons, especially at known screen densities. However, the memory numbers and exec times still seem out of line, and likely affect non-icon SVG usage as well.

On a Nexus 4 with the patches for bug 590790 the memory report goes from 80% heap-unclassified to 18% heap-unclassified. More specifically from: 45.08 MB (100.0%) -- explicit ├──36.02 MB (79.90%) ── heap-unclassified ├───3.89 MB (08.63%) -- heap-overhead │ ├──3.54 MB (07.85%) ── waste │ └──0.35 MB (00.78%) ++ (2 tiny) ├───2.58 MB (05.72%) -- js-non-window │ ├──1.61 MB (03.57%) -- zones │ │ ├──0.91 MB (02.01%) -- zone(0xb3b33c00) │ │ │ ├──0.48 MB (01.07%) ++ compartment([System Principal]) │ │ │ └──0.42 MB (00.94%) ++ (8 tiny) │ │ ├──0.48 MB (01.07%) -- zone(0xb3f07800) │ │ │ ├──0.46 MB (01.02%) ++ strings/string(<non-notable strings>) │ │ │ └──0.02 MB (00.04%) ++ (4 tiny) │ │ └──0.22 MB (00.49%) ++ zone(0xb3f0a400) │ ├──0.94 MB (02.08%) ++ runtime │ └──0.03 MB (00.07%) ++ gc-heap ├───1.20 MB (02.67%) ++ (16 tiny) ├───0.85 MB (01.89%) ── xpti-working-set └───0.54 MB (01.19%) -- window-objects/top(app://template.gaiamobile.org/index.html, id=1) ├──0.46 MB (01.03%) ++ active/window(app://template.gaiamobile.org/index.html) └──0.07 MB (00.16%) ++ js-zone(0xb349e000) to: 45.14 MB (100.0%) -- explicit ├──27.88 MB (61.76%) -- images │ ├──27.88 MB (61.76%) ++ vector/content/used/documents │ └───0.00 MB (00.00%) ++ raster ├───8.18 MB (18.11%) ── heap-unclassified ├───3.91 MB (08.67%) -- heap-overhead │ ├──3.51 MB (07.77%) ── waste │ └──0.41 MB (00.90%) ++ (2 tiny) ├───2.58 MB (05.71%) -- js-non-window │ ├──1.61 MB (03.56%) -- zones │ │ ├──0.91 MB (02.01%) -- zone(0xb3c33c00) │ │ │ ├──0.48 MB (01.07%) ++ compartment([System Principal]) │ │ │ └──0.42 MB (00.94%) ++ (8 tiny) │ │ ├──0.48 MB (01.07%) -- zone(0xb4007800) │ │ │ ├──0.46 MB (01.02%) ++ strings/string(<non-notable strings>) │ │ │ └──0.02 MB (00.04%) ++ (4 tiny) │ │ └──0.22 MB (00.49%) ++ zone(0xb400a400) │ ├──0.94 MB (02.08%) ++ runtime │ └──0.03 MB (00.07%) ++ gc-heap ├───1.20 MB (02.66%) ++ (15 tiny) ├───0.85 MB (01.89%) ── xpti-working-set └───0.54 MB (01.19%) -- window-objects/top(app://template.gaiamobile.org/index.html, id=1) ├──0.46 MB (01.03%) ++ active/window(app://template.gaiamobile.org/index.html) └──0.07 MB (00.16%) ++ js-zone(0xb359e000)

Each individual vector image's SVGDocument reports 0.14 MB of memory usage (00.31% of the total).

We're still definitely under-reporting SVG memory usage, but with the patches for bug 590790 reporting 61.76% of memory going to vector image documents with only 18.11% being heap-unclassified, we're reporting at least 75% of the SVG documents' memory usage. Since even in the PNG memory report (http://ricaud.me/mozilla/svg-benchmark/png-foreground/memory-reports) 11.61% of the memory is unclassified, I suspect the SVG documents' are reporting more like 85-90% of their memory. I've been working on using DMD to get other SVG memory reporters to make the report more complete in this case, but since we now know where the majority is going I decided to provide the above (and following) information now before finishing that.

When loaded directly in the Browser on the Nexus 4 the contacts.svg file reports the following breakdown of memory usage: 0.42 MB (04.27%) -- top(http://ricaud.me/mozilla/svg-benchmark/contacts.svg, id=4) ├──0.31 MB (03.09%) -- active/window(http://ricaud.me/mozilla/svg-benchmark/contacts.svg) │ ├──0.16 MB (01.60%) -- layout | │ ├──0.12 MB (01.17%) ── style-sets │ │ └──0.04 MB (00.43%) -- (5 tiny) │ │ ├──0.03 MB (00.31%) ── pres-shell │ │ ├──0.01 MB (00.07%) ── rule-nodes │ │ ├──0.00 MB (00.02%) ── style-contexts │ │ ├──0.00 MB (00.02%) ── frames/sundries │ │ └──0.00 MB (00.01%) ── pres-contexts │ ├──0.14 MB (01.36%) ++ js-compartment(http://ricaud.me/mozilla/svg-benchmark/contacts.svg) │ └──0.01 MB (00.12%) -- (3 tiny) │ ├──0.01 MB (00.07%) -- dom │ │ ├──0.00 MB (00.04%) ── other [2] │ │ ├──0.00 MB (00.03%) ── element-nodes │ │ └──0.00 MB (00.00%) ── event-targets [2] │ ├──0.00 MB (00.05%) ── style-sheets │ └──0.00 MB (00.01%) ── property-tables └──0.12 MB (01.18%) -- js-zone(0xb359dc00) ├──0.11 MB (01.07%) ── unused-gc-things └──0.01 MB (00.10%) ++ (2 tiny) Note that when the SVG is loaded as an image there is no window object, and JS doesn't run so there's no memory used for js-compartment/js-zone. So the ~17 MB reported here for layout, dom, style-sheets and property-tables isn't too far off the 14 MB noted in comment 5. (Presumably different slop and rounding accounts for the difference?) Anyway, this shows that as far as the memory usage side of this bug goes, the main culprit here is definitely style-set memory usage, which is bug 686875.

A bit of an update: The HUD reported memory use on the keon of the test app when the number of SVG images is changed from 200 to 400 changes as follows with the patches from the following bugs: current: 44,589,056 B -> 79,671,296 B (175,411 B per image) bug 1008455: 39,833,600 B -> 66,240,512 B (132,035 B per image) bug 1013936: 28,934,144 B -> 44,638,208 B ( 78,520 B per image) bug 1011806: 21,176,320 B -> 33,333,248 B ( 60,785 B per image) Not a perfect way to measure, but probably as good as any ATM. The respective reported about:memory per image sizes are: 146,684 B 113,692 B 58,812 B 37,068 B The HUD based measurements would imply a 66% decrease in memory use per SVG image from these bugs, whereas the about:memory based measurements would imply a 75% decrease.

Wow that's amazing progress in only 3 bugs! Great job! http://ricaud.me/images/success.gif

Bug 1015147 saves us a further ~12,145 B per image (based on 200 -> 400 image HUD measurement) taking us to ~48,640 B per image and a running total of a ~72% reduction in memory per image.

(In reply to Anthony Ricaud (:rik) from comment #9) > Wow that's amazing progress in only 3 bugs! Great job! Thanks. Unfortunately we need to find yet more big savings to get close to being comparable to PNG. (And some of the patches in the blocking bugs are proving a headache to land, and it could well be bumpy once they do.) Still, its good forward progress.

Where I've said "HUD" above I meant about:memory totals (which account for dark matter). Where I said "The respective reported about:memory per image sizes are..." these are the measurements reported to about:memory by the SVGDocument instances (too low, since they don't account for dark matter). Sorry for any confusion; I was using the HUD early on in my testing but then switched to the about:memory totals as an equivalent when actually logging my measurements.

The four patch sets I've been working on (bug 1008455, bug 1011806, bug 1013936 and bug 1015147) have now landed on inbound. Here's a summary of the impact that had on this bug's benchmark on the keon. "Baseline" below means the commit immediately before the four patch sets (21d0c653afa1), and "new" means the perf immediately after the four patch sets landed (3d3d1e8d9a6e). The memory values reported are the root "explicit" value of the the modified Template (the benchmark) process as given by about:memory pulls from the device. baseline: 51,892,224 B 200 <img>s 87,543,808 B 400 <img>s 35,651,584 B delta 178,257.92 for each extra <img> new: 29,360,128 B 200 <img>s 39,739,392 B 400 <img>s 10,379,264 B delta 51,896.32 for each extra <img> 178,257.92 - 51,896.32 = 126,361.6 51,896.32 / 178,257.92 = 0.29113051 So this gave us a reduction of about ~126,361 B per <img> referencing SVG, which is just over a 70% reduction per <img> on the benchmark. Since these numbers include DOM, layout and other things related to the <img> elements in the referencing document the actual reduction for the SVG itself will be somewhat greater than 70%. In terms of start-up time, the Developer HUD reports: baseline: 5809 5810 5907 (~5842) new: 4330 4369 4432 (~4377) So about a 25% reduction in start-up time.

Based on the state after the four patch sets landed (3d3d1e8d9a6e), on the keon we're now roughly at: Load times: SVG: ~4377ms; PNG: ~2972ms Total app memory: SVG: 30.1MB; PNG: 21.6MB Per-<img> memory: SVG: 51.9KB; PNG 12.3KB So we're still some way off despite the improvements. A further 70%+ reduction in contacts.svg's memory usage when used as-an-image memory ought to do it for the memory use...

Just a heads-up: Firefox Desktop is also interested in using SVG to draw our icons, and we've identified a subset of SVG features that we need in order to draw those icons. We've filed bug 1027080 to start tackling that subset.