Web Console changes in Aurora (Firefox 15)
6 June 2012, 10:35
Hello Mozillians!
For the Aurora update that's happening this week we have some major changes under the hood for the Web Console.
Async Web Console
Work on making the Web Console UI async, decoupled from all the error and network listeners, started in July last year (bug 673148). Even if it took almost one year to get this bug fixed, I worked on these patches for about 3 months (loosely summing up the total days of work spent on this specific bug).
Back in those months we strongly pushed for various developer tools to land and get enabled by default in Firefox. I've been working a lot on the source editor which was needed for the Style Editor, the JS debugger and Scratchpad. Work on the Web Console was on and off.
There was modest to good progress for the Web Console async work until around September - October when Mozilla's electrolysis project was re-prioritized. The initial work on the patch started out with the goal of making the Web Console ready for e10s. When priorities changed, I went back to source editor work which was higher priority at that point.
In January - February a really brave and courageous contributor, Sonny Piers, took the huge patch and rebased it. His efforts were commendable given the size and complexity of the work that was going on. Thank you Sonny!
In March I resumed work and I strongly focused on completing the async patches. Last week the last patch landed in the nightly builds of Firefox.
What changed? Most of the Web Console was implemented in a single file, HUDService.jsm.
It had everything - from UI code to all the error and network listeners and stuff for the window.console API.
We have now broken that code into separate scripts with the goal to leave
HUDService.jsm as the script that implements only the UI. The new HUDService-content.js script
implements all the listeners, all the "backend stuff". The UI code must no longer directly access the content window and
objects from the content document.
Why? This work allows us to move to the remote debug protocol and to have the Web Console UI connect to your Firefox Mobile or B2G device where all the error and network listeners are instanced. This work paves the way to a remotable Web Console.
The added benefit is that the async-ness had some modest performance benefits to content scripts (pages) that used the
window.console API - a call to any method no longer had to wait for the Web Console UI parts to update.
In the future other Firefox components and extensions can build different UIs on top of the data collected by the
HUDService-content.js script.
Lessons learned:
- Focus, focus and focus! Given big projects one must not try to do everything else.
- Do not underestimate the time it takes to polish working code, to make it ready for review. I had working code in September-October, but getting it "done" took quite more.
- Make sure your manager is aware there's a ton of work to do on your project. There's high temptation to be nice and be helpful and do a lot of other work in between. ;)
- Aggressively split your work into smaller chunks.
- Be lazy - avoid doing work you don't need to do for the given goal project.
Thanks go to Rob Campbell, Dave Camp, Felipe Gomez, Ms2ger, Joe Walker, Sonny Piers and everyone else who contributed to getting these patches to be ready to land.
Improved performance
Building on top of the async Web Console work we've also made some really nice output performance improvements (bug 722685). In bug 746869 Boris Zbarsky analyzed the performance issues in our code and he made a number of valuable suggestions on how we can make it faster. Thank you Boris!
Our first attempt to make the Web Console output faster has landed in Firefox. Let's go straight for the numbers:
-
Opera 12 (post-beta, latest snapshot, with "cutting-edge" Dragonfly):
-
Closed console:
- Simple string: 4 ms
- Interpolation: 1 ms
-
Open console:
- Simple string: 17 ms
- Interpolation: 12 ms
Display performance is sufficiently good. However, it becomes slow to very slow after several runs. No message pruning happens.
-
-
Chromium 18 (beta):
-
Closed console:
- Simple string: 21 ms
- Interpolation: 11 ms
-
Open console:
- Simple string: 66 ms
- Interpolation: 68 ms
Performance in content pages is very good. However, display performance is actually poor. First run is fast. Subsequent runs take far more. The web inspector tool UI is frozen for many seconds when the second and third runs happen. Content process separation helps a lot. Even if Web Inspector's display is frozen, web pages continue to run smoothly.
-
-
Firefox 13 (without the async patches):
-
Closed console:
- Simple string: 135 ms
- Interpolation: 128 ms
-
Open console:
- Simple string: 6941 ms
- Interpolation: 7376 ms
Firefox locks up badly, turns gray (frozen). Subsequent runs take the same amount of time - not slower. We prune old messages.
-
-
Firefox 15 nightly (with the async patches landed):
-
Closed console:
- Simple string: 139 ms
- Interpolation: 134 ms
-
Open console:
- Simple string: 235 ms
- Interpolation: 240 ms
Firefox freezes for less time, it doesn't turn gray on Ubuntu and content script impact is reduced. Subsequent runs are not slower.
-
-
Firefox 15 Aurora (with the performance patch landed):
-
Closed console:
- Simple string: 50 ms
- Interpolated string: 48 ms
-
Open console:
- Simple string: 51 ms
- Interpolated string: 48 ms
For comparison: do note that 1000
dump()calls take around 10-20 ms in Firefox. (dump()is a dumb method we use to output messages to STDOUT.)Having the Web Console open or closed no longer directly impacts console API calls. Now the UI no longer freezes and results show up quickly.
I tried with 5000 calls and we now do better than Opera's Dragonfly and Chrome's Web Inspector - in terms of UI updates. Still, console API calls finish faster, for some reason, in those two browsers.
-
Please do note that I used the simple test attached to bug 722685 for testing. These numbers are not meant to be "scientific" or anything like that - they are based on my machine setup.
We will continue to do further work in improving the output performance (bug 761257). At this point we still need to avoid doing some unneeded work when a lot of messages end up in the queue to be displayed. We also need to better balance how often and how many messages we display during "heavy fire" - during the execution of content scripts that invoke the console API methods many, many times for an extended period of time.
What's next?
We have plans to move the Web Console UI into its own
<iframe>, change the UI to match the other developer tools theme, add the option to move the UI
into a real window, make a global console that could replace the Error Console and, obviously, switch to the remote
debug protocol so you can use the Web Console with remote Firefox instances. All this and many other improvements, of
course!
You may wonder "when?" and the answer to that is that all the improvements will come gradually when we get to implement them.
File bugs, find regressions and let us know what you like and dislike! Thank you!