It's runs/sec also degrade as we proceed through the iterations, presumably because GCs start to take a really long time. Hilariously, if you "test again", we will keep growing the heap. Dunno if it's a leak in Speedometer or in our engine. Making it a JSC bug for now.
Hm... we should probably check the leak in other engines like Chrome to see if this is a benchmark issue vs engine issue.
<rdar://problem/36007410>
I've measured this in Chrome using heap snapshots. Their memory usage starts off at ~4MB then goes up to ~24MB but stabilizes around that range at the end. I've also monitored the process's memory usage, and they do go up to ~200MB but stays there the whole time, and re-running the test doesn't increased the memory usage.
I've also measured this in Firefox. Their memory usages starts off around 500MB and goes up to ~580MB. In the second run, however, it can go up to ~680MB despite of the fact their usage temporarily dropped to ~510MB at the beginning of the test. The leak memory usage in the third run is stays around ~720MB but then drops to 520MB if I wait ~5s after the test had finished running. So I suspect this isn't the same leak we're seeing but more about their memory getting fragmented over time, or that their GC/malloc holding onto more pages in later runs.
As far as I can tell, we're leaking every window object in both Speedometer 1 & Speedometer 2.
Saam and I looked into this, and we can no longer reproduce it. It looks like this reproduces when Inspector is open so it's possible we both had Web Inspector open when we did the measurement? Regardless, there isn't anything actionable here.
If this is Web Inspector only, does the memory at least get reclaimed when Web Inspector closes?
(In reply to Joseph Pecoraro from comment #7) > If this is Web Inspector only, does the memory at least get reclaimed when > Web Inspector closes? Yes, we think it's inspector only. The memory does get reclaimed after a few seconds when inspector closes.