« "Why Cairo?" | Main | Gran Paradiso Alpha 1 and SVG »
April 25, 2006
"Why so big?"
One question that people have about our implementation is why we use so much memory. Robert O'Callahan had one opinion regarding this, and we are indeed fixing some of those issue. Recently while changing how path data was stored, I ran a torture case through the valgrind massif heap profiler and came up with some interesting data.
The testcase in question is the Renesis plan.svg, a 30MB SVG file that they use for demoing their implementation. They can load it in about 6-7 seconds and use about 50MB. A debug mozilla build takes about 1:50 and about 267MB. Looking at what plan.svg contains, it breaks down like this:
| Element | Count |
|---|---|
| defs | 1 |
| ellipse | 10051 |
| text | 1719 |
| a | 1 |
| tspan | 48 |
| use | 96 |
| polygon | 4 |
| path | 157944 |
| pattern | 1 |
| rect | 1 |
| g | 117193 |
| svg | 1 |
The output of running this through massif (with annotations added by me) is as follows. This is on a build with the path data storage change from bug 334999 - a trunk build would probably have the small objects used for path storage grouped into "other". The associated html output file is available here.
As you can see, it seems that the largest memory user is strings and associated data for generic attribute storage. However the 60MB+ it uses seems excessive for a 30MB file. Not sure what's happening here - opinions of gecko experts welcome.
Losing about 25MB for malloc control overhead seems like a serious problem, if that number is indeed correct for the glibc allocator. It suggests that we're allocating an excessive number of small objects. Some of this is likely from the unconverted SVG base types, but getting a better handle on what is causing this would be good.
SVG Frames take a considerable amount of memory, and is one of the things we're actively working on cutting down, so we can ignore that for purposes of evaluating the graph for now.
Elements take a fair amount of space. Some reduction could be done using properties for infrequently used fields.
Posted by tor at April 25, 2006 7:18 PM
Comments
Yes, mozilla has been a bad case for malloc overhead for a long time.
Posted by: graydon at April 26, 2006 1:45 AM
Hm. Link seems to have been erased. Meant to post this: http://gee.cs.oswego.edu/dl/malloc-plots/index.html
Posted by: graydon at April 26, 2006 1:45 AM
Would it be possible to instrument allocation of nsStringBuffer to dump a stack every thousand allocations of so to get a feel for where these strings are being allocated? I do agree that having that much string data is a tad odd...
Posted by: Boris at April 26, 2006 4:25 PM
So the file has about 25 million characters worth of "d" attributes on nodes. Just that will take up 50MB in Gecko (each char is 2 bytes in UTF16, for our purposes).
Posted by: Boris at May 1, 2006 5:25 PM
It's nice
Posted by: fish_hfd at June 30, 2007 6:46 AM