Open Bug 698919 Opened 8 years ago Updated Last year
[meta] specific improvements to reduce impact of the cycle collector on responsiveness
The cycle collector can cause unpleasant pause times, especially when things get leaky. We should attempt to both reduce the length of those pauses (by improving cycle collector performance and investigating incremental approaches), and make them less annoying by being smarter about when and if we schedule the cycle collector to run. We should also gather together bug reports where people report long CC pause times, but maybe it would make more sense to track that in a separate bug. For reference, when I measured the cycle collector time (using shark and time logging), with a few tabs and some browsing around, cycle collector time was dominated by building the graph. Most of the time graph building takes about 90% of the 40ms to 120ms ish cycle collector time. Sometimes unlinking takes about a third of the cycle collector time, presumably when we close a tab and the CC has to free a bunch of things. At the first shutdown CC, unlinking takes more time than building the graph, but I think that's unusual. Of course, these "normal" CC times may not reflect the breakdown when things are getting slow, but they are a starting point.
Summary: reduce impact of cycle collector on responsiveness → [meta] reduce impact of cycle collector on responsiveness
There's also bug 646941 (which I haven't confirmed because I haven't seen these pauses since Firefox 3.6). Should this one be marked a dupe?
No, this is a meta bug for tracking various specific approaches for reducing the impact of cycle collector pause times. It would probably be good to have a separate meta bug for tracking various instances of the CC/GC getting slower. Unfortunately, those tend to be very hard to figure out.
Summary: [meta] reduce impact of cycle collector on responsiveness → [meta] specific steps to reduce impact of the cycle collector on responsiveness
Summary: [meta] specific steps to reduce impact of the cycle collector on responsiveness → [meta] specific improvements to reduce impact of the cycle collector on responsiveness
There's going to be a meeting tomorrow on improving/measuring browser responsiveness: http://groups.google.com/group/mozilla.dev.planning/browse_thread/thread/d9d0d4e3675067e3 I'll attend and take notes on cycle collector related things that are discussed.
Randell Jesup saw TraverseExpandoObjects() take up a huge amount of time in a long CC in bug 696761, and Peter thinks Bug 700668 will help reduce that.
Depends on: 700668
In terms of figuring out where we are spending time, Smaug says "looks like in some cases unlinking takes more time than unroot, but not always. And rooting is quite cheap".
I guess I'll mark this as [Snappy:P1], as the cycle collector is a big source of pauses, but I'm not sure if a meta bug is appropriate for tracking like this or not.
Whiteboard: [Snappy] → [Snappy:P1]
Whiteboard: [Snappy:P1] → [Snappy:P1] (we should snappy nom and priority sub bugs)
Whiteboard: [Snappy:P1] (we should snappy nom and priority sub bugs) → [Snappy:P1]
Moved a bunch of these bugs into a sub-meta-bug.
I guess it's now effective on nightly because ffx has massively improved its score on the spinning balls v8 bench (http://v8.googlecode.com/svn/branches/bleeding_edge/benchmarks/spinning-balls/index.html). A few weeks ago, I had around 800ms delays each 7 seconds (even after Incremental GC activation) and now the biggest one is around 400ms. You made a wonderful work and without loosing this big part (1/3) of balls managed in less than 20ms. Bravo and merci to make the web ( so mine :) ) better!
Thanks for the feedback! Personally, at least when testing with nothing else open in my browser, it was always GC pauses that were happening, not CC. billm has landed a number of GC improvements over the last few weeks to improve incremental GC, so that's probably more to blame for your improvement than any changes to the CC we have made.
Ok thanks for the explanation and for your work, of you and billm, again. I just thought that a better cycles management meant less garbage to deal with for the CG (but I have not enough time to go deep in FFX's sources to be sure). Anyway, it's a pleasure to see the fast evolution of Mozilla.
Noming for Kilimanjaro blocking due to the requirement "Content performance (gc+cc pauses and fps)". Note that there may be a more specific subset of this work that we actually want to target.
blocking-kilimanjaro: --- → ?
It is probably bug 741417, since when there are no cycles to collect, CC time should be reasonable low, almost low enough.
Dropping Kilimanjaro nom from this bug in favour of bug 741417 and bug 728407 as suggested by Olli.
No longer blocks: k9o-perf
blocking-kilimanjaro: ? → ---
No longer blocks: 638299
This is a meta bug, and CC performance is not so bad any more, so this doesn't really need an assignee or a Snappy tag.
Assignee: continuation → nobody
You need to log in before you can comment on or make changes to this bug.