The meeting was short this time because all of the participating people in the Toronto office conspired be busy or on vacation today.
Our UX team helped us decide to turn on tabs-on-demand + do tab restore by default, Bug 711193. This change will make interacting with the browser more responsive after startup, help MemShink and not trigger as much captive wifi portal badness.
Frontend people are busy adding telemetry to everything that matters, bug 671038. Some of this has already paid off in terms of us catching a tab animation regression in bug 724349. We plan to switch our awesomebar searching from SQL to an FTS. If you are a text-search/tokenizer expert, perhaps you help us with bug 725821. There is also a lot of activity on making various sync IO things async, see the meeting notes for complete details.
Brian Bondy posted an update documenting his two-week rampage through Firefox startup inefficiencies on Windows. Brian’s blog post contains tips on xperf, Firefox profiler, about:startup – read it.
The networking team is busy nuking the big cache lock, see bug 717761.
Olli has landed most of the cycle collector fixes. Telemetry shows a dramatic reduction in cycle collection times for Firefox 13. He and Andrew investigating the remaining causes of long CC times.
I’ll end this post with a pretty picture demonstrating recent cycle collection improvements.
* y: frequency, x: milliseconds
Why don’t you label the axes in your graph? It seems like a very bad habit of programmers to be sloppy with graphs.
Nice update, and keep up the good job!
I have one snappy issue with Firefox (starting with firefox 9?). When I use SkyDrive, the Firefox causes a high CPU usage and gets unresponsive. xperf shows those functions with high CPU usage:
mozjs.dll!JSC::Yarr::Interpreter::matchDisjunction (11%)
mozjs.dll!JSC::Yarr::Interpreter::testCharacterClass (7.60%)
mozjs.dll!JSC::Yarr::Interpreter::backtrackCharacterClass (1.79%)
JSC::Yarr::Interpreter::matchCharacterClass (1.67%)
Is there any Plan or bug to address the CSS::ProcessRestyles jank? I guess most of the time this function takes a lot of time if it is processing a lot of elements. Maybe it is possible to make this more interruptable and/or async?
André: file a bug for that?
kamulos: can’t be done in general. The only thing we can do is speed up selector matching.
Taras: do we have data to show that switching awesomebar searching from SQL to FTS can definitely be a win? I thought we did not. Without that data, why are we planning to switch?
I personally find I get random and very laggy – sometimes it seems as long as 10 seconds – delays when trying to use the (not always so) awesomebar’s drop menu. I can’t seem to narrow this down except that it happens when I’ve been away from the browser most of the time.
This has been a problem since day 1 of the awesomebar for me. If switching from SQLite resolves this problem, it would be a great improvement IMHO.
Keep up the great work everyone. Americans seem to have developed an ever-increasing stupid habit of taking the piss out of Canadians. This is not the case in the rest of the world despite the tar sands evil. Something tells me Colbert has a lot of answer for!
@pd, if you can narrow it down that’ be great. if you install the about:telemetry extension, it’ll tell you about sql queries that take over 100ms.
Firefox starts a bunch of maintenance stuff in the background, which hurts when you come back. I would like to mark most of that as cancellable, so it doesn’t have to block the user.
re blame canada: that’s a south park reference.