User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:2.0b6pre) Gecko/20100911 Firefox/4.0b6pre Build Identifier: Built from http://hg.mozilla.org/mozilla-central/rev/f1bd314e64ac Not really a specific bug, but rather a meta bug for issues that can cause poor performance on the foreground tab while background tabs are being loaded. Reproducible: Always Steps to Reproduce: 1.Open https://bugzilla.mozilla.org/buglist.cgi?quicksearch=html in a background tab 2.Scroll on the foreground tab Actual Results: Scrolling stutters. Expected Results: Scrolling should be smooth. Note that this isn't a scrolling specific bug, various things like Awesome bar results and editing text slowdown when loading background tabs. This isn't a regression either.

Isn't this basically a duplicate of "implement e10s"?

(In reply to comment #1) > Isn't this basically a duplicate of "implement e10s"? Probably, but aren't there any "stopgap fixes" in the Firefox 4 time-frame before e10s happens? (Like the various cache fixes that were done since bug 512849 was out of scope for Fx4)

> Probably, but aren't there any "stopgap fixes" We've done a number of those already, no (e.g. throttling the refresh driver in background tabs, etc)? Do you have any specific proposals that you think should be considered?

(In reply to comment #3) > We've done a number of those already, no (e.g. throttling the refresh driver in > background tabs, etc)? Do you have any specific proposals that you think > should be considered? Moving stuff that happens on the main-thread (DOM, JS stuff) off to another thread, doing asynchronous image decoding (or simply bug 573583), don't generate JIT code (not sure if this would actually help anything) and doing lazy error reporting (bug 520566) for background tabs. There are probably many ways of fixing this and various open bugs (specially I/O related such as bug 513008 and bug 5497670) could help here, the problem is whether or not they are worth fixing before e10s happens.

This is not a bug for a regression since 3.6, right?

> off to another thread That's comparable in scope to the scope of e10s when it was started, actually. In fact, doing that would have serious performance hits; we've been moving towards _reducing_ the multithreading support in the JS engine, with an eye to turning it off. > doing asynchronous image decoding (or simply bug 573583) That's already being done, right? > don't generate JIT code (not sure if this would actually help anything) It wouldn't; we generate jit code lazily when the code being jitted actually runs, and the whole point is that the jit + run time is smaller than interp runtime. > doing lazy error reporting (bug 520566) for background tabs. Error reporting takes up a minuscule amount of time. The bug you link to is talking about 5% of something that takes less than 1% of pageload, typically. In any case, if you want to use this as a meta bug, go ahead; might want to actually add some deps to it then.

Boris, if any of the dependencies I added here won't actually help this bug feel free to remove them, and also to add any new ones which I might have missed.

Henri, we have several knobs that we can turn for how the parser and DOM construction and layout notifications happen, and it seems we could look into tuning that differently for background tabs than we do for foreground tabs. We could even look into intentionally slowing down feeding data from the parser thread to the main thread when loaded in the background.

(In reply to Johnny Stenback (:jst, jst@mozilla.com) from comment #11) > Henri, we have several knobs that we can turn for how the parser and DOM > construction and layout notifications happen, and it seems we could look > into tuning that differently for background tabs than we do for foreground > tabs. On the main thread, we could vary these tunables for background tabs: http://mxr.mozilla.org/mozilla-central/source/content/base/src/nsContentSink.cpp#241 > We could even look into intentionally slowing down feeding data from > the parser thread to the main thread when loaded in the background. Intentionally slowing down feeding the parser thread could easily lead to accidents where data waits unnecessarily, because the foreground tab isn't really that busy. We currently have only one parser thread that serves all active HTML parsers. What the parser really needs is a task queue whose tasks get executed serially, but it doesn't really matter if one thread ends up running all the tasks for a given parser. What we could do is giving each nsHtml5StreamParser a queue of nsIRunnables that's separate from threads and having two or more threads that take tasks from those queues and run them in such a way that the queues belonging to frames in the frontmost tab get priority.

(In reply to Henri Sivonen (:hsivonen) from comment #12) > (In reply to Johnny Stenback (:jst, jst@mozilla.com) from comment #11) > > Henri, we have several knobs that we can turn for how the parser and DOM > > construction and layout notifications happen, and it seems we could look > > into tuning that differently for background tabs than we do for foreground > > tabs. > > On the main thread, we could vary these tunables for background tabs: > http://mxr.mozilla.org/mozilla-central/source/content/base/src/nsContentSink. > cpp#241 Even without making any difference between background and foreground tabs, the app could be made more responsive by tuning those numbers. The problem is that there's a tradeoff between responsiveness and throughput, so it's really hard to change anything there in *any* way towards responsiveness without regressing tp.

Yup, understood. But I think we're getting to a point where we're willing to pay some in page load time to get more responsiveness here. I say this is definitely worth exploring!

Is bug 76495 a dupe or dependancy?

Marking all tracking bugs which haven't been updated since 2014 as INCOMPLETE. If this bug is still relevant, please reopen it and move it into a bugzilla component related to the work being tracked. The Core: Tracking component will no longer be used.