SPSProfiler::strings is initialized like this: strings.init(max) and in Gecko |max| is 1,024. This ends up giving us a hashtable with 2,048 entries, which takes up 24,576 bytes on 32-bit platforms, and 49,152 bytes on 64-bit platforms. This is overkill.
Created attachment 677659 [details] [diff] [review] Reduce the initial size of SPS's strings hashtable. This patch causes the hashtable to initialize to the default size (32 entries), which results in a 512 byte table on 32-bit platforms and a 1,024 byte table on 64-bit platforms. This avoids wasting space when SPS isn't used, and when SPS is used the table will quickly grow (with negligible overhead) to a suitable size (which may still be substantially less than 2,048 entries). This is a tiny win, but hey! It's a tiny patch. And it saves me from having to see it come up in memory profiles all the time.
Comment on attachment 677659 [details] [diff] [review] Reduce the initial size of SPS's strings hashtable. [Approval Request Comment] Bug caused by (feature/regressing bug #): N/A. User impact if declined: slightly higher memory consumption on B2G; the patch saves 24 KiB per B2G process. Testing completed (on m-c, etc.): just landed on m-c. Risk to taking this patch (and alternatives if risky): negligible. It just reduces the initial size of a hashtable that's only used if the SPS profiler is enabled. (There's no functionality change; the table will grow as needed if the SPS profiler is enabled.) String or UUID changes made by this patch: