Surprise of the week
[Update: This analysis about livemarks may be wrong. Talos results from early September show that the MaxHeaps number increased, and the reduction when the “Latest Headlines” livemark was removed has undone that increase. So livemarks may not be responsible at all, it could just be a coincidence. More investigation is needed!]
Jeff Muizelaar removed the “Latest Headlines” live bookmark from new profiles. This was in the Bookmarks Toolbar, and so hasn’t been visible since Firefox 4.0, and most people don’t use it. And it uses a non-zero amount of memory and CPU. Just how non-zero was unclear until Marco Bonardo noticed some big performance improvements. First, in the Talos “MaxHeap” results on WinNT5.2:
And secondly in the Talos “Allocs” results on WinNT5.2 and Mac10.5.2:
In the WinNT5.2 cases, it looks like we had a bi-modal distribution previously, and this patch changed things so that the higher of the two cases never occurred. In the Mac10.5.2 case we just had a simple reduction in the number of allocations. On Linux the results were less conclusive, but there may have been a similar if smaller effect.
This surprised me greatly. I’ve done a lot of memory profiling of Firefox and never seen anything that pointed to the feed reader as using a lot of memory. This may be because the feed reader’s usage is falling into a larger, innocuous bucket, such as JS or generic strings. Or maybe I just missed the signs altogether.
Some conclusions and questions:
- If you have live bookmarks in your bookmarks toolbar, remove them! [Update: I meant to say “unused live bookmarks”.]
- We need to work out what is going on with the feed reader, and optimize its memory usage.
- Can we disable unused live bookmarks for existing users?
Apparently nobody really owns the feed reader, because previous contributors to it have all moved on. So I’m planning to investigate, but I don’t know the first thing about it. Any help would be welcome!
There was a huge memory leak in the Video DownloadHelper add-on v4.9.5, and possibly earlier versions. This has been fixed in v4.9.6a3 and the fix will make it into the final version v4.9.6 when it is released. That’s one more add-on leak down, I wonder how many more there are to go.
TraceMonkey, the trace JIT, is no longer built by default. This means it’s no longer used, and this saves both code and data space. The old combination of TraceMonkey and JaegerMonkey is slower than the new combination of JaegerMonkey with type inference, and TraceMonkey is also preventing various clean-ups and simplifications, so it’ll be removed entirely soon.
I refined the JS memory reporters in about:memory to give more information about objects, shapes and property tables.
I wrote about various upcoming memory optimizations in the JS engine.
Justin Lebar enabled jemalloc on MacOS 10.5 builds. This was expected to be a space improvement, but it also reduced the “Tp5 MozAfterPaint” page loading benchmark by 8%.
Robert O’Callahan avoided excessive memory usage in certain DOM animations on Windows.
- P1: 35 (-1, +1)
- P2: 116 (-2, +5)
- P3: 55 (-2, +3)
- Unprioritized: 5 (-4, +5)
At this week’s MemShrink meeting we only had 9 bugs to triage, which is the lowest we’ve had in a long time. It feels like the MemShrink bug list is growing slower than in the past.