This module somehow has quite some memory in use in a content process (~ 11 kB).
We need to find out where and how to eliminate that usage.
> The `Timers._timers` map never empties so it tends to end up storing concrete references to a dozen or so WeakMaps.
> Not sure that accounts for the full 11kB, but it might be a chunk of it.
From this it seems as though all the costs are in bytecode? I assume that's what "script" means.
jan-erik, am I interpreting this correctly? Are we expected to optimize for generated bytecode size?
Hey :mccr8, as the one that wrote the dom_tree script, could you shine some light on the details of what these numbers mean and what we can do?
So far I was able to split up our scripts to reduce memory usage, but for this one we're already pretty minimal.
We can't avoid loading TelemetryStopwatch in content processes.
The first entry means that there's a blob of JS stuff (objects, scripts, etc.) where there's some single thing holding the rest of it alive. The total size of all of that stuff is 3.1kb. Somewhere in that blob is the script for TelemetryStopwatchImpl.timeElapsed(), and there is no other script in that blob.
That file does look pretty trimmed down. You could try looking at the GC edges file for the object that contains "TelemetryStopwatchImpl.timeElapsed" in the description and see what it is pointing to. Maybe that will help. My only guess is that maybe those error strings are the cause of some of the memory? It seems suspicious that the 3 methods with errors are showing up, and the one with two errors has twice as much memory. You could try commenting all of that out and see what happens.
Thanks for looking at this. I'm sorry I haven't updated the patch in bug 1463569 in a while. I should put that on my to do list.
There are 21 atom lines, four scopes, one sourceObject and one lazyScript.
...I presume it just goes on like this with string atoms for each part of the error strings individually pulled out.
What's interesting to me is the presence of things that aren't strings, like "Cu" and "_suppressErrors".
I don't think there's much to be done if all the allocations are overhead for scopes and string pieces. We could try to optimize for shorter error messages, I suppose, but that seems kinda odd.
For a source file 16k in size, with most of its source reproduced as strings in the engine and the rest covered in pointers, should we really be surprised that it is 11k?
I'm going to mark this Invalid as there doesn't seem to be much worth doing here.
:kmag, could you give me a quick precis of why this has been reopened? I'm eager to learn what I might have missed.
:kmag Please take a look.