Hidden cost of (not) using Venkman

I came across a Venkman “feature” that was so unexpected that I even filed a JavaScript engine bug on it. Only after Gijs Kruitbosch asked me to test with a clean profile I realized that the JavaScript performance issue I was seeing wasn’t inherent to Firefox but rather something the Venkman extension was responsible for. That’s right, Venkman is degrading JavaScript performance just by being installed, even if you don’t use it. I had Venkman installed “just in case” and this was a big surprise to me.

The technical details: any JavaScript debugger for Firefox (be it Venkman, Firebug or my JavaScript Deobfuscator) uses the debugging interface of the JavaScript engine, it merely serves as a user interface for it. Usually the debugging interface is turned off and only switched on when necessary. The reason for this: when the debugging interface is switched on it makes the JavaScript engine do some bookkeeping which has an impact on performance (about 15% on the SunSpider benchmark according to my measurement).

The problem is: Venkman turns on the debugging interface on browser startup so that it is active throughout the entire browser session. And that’s independent of whether you are actually using the debugger. The only way to turn off this behavior is typing the following command on the Venkman command line:

/startup-init off

This will only work until you install a new extension or upgrade Firefox, after that the setting will be reset.

Why is Venkman doing something like this? The problem is apparently that Venkman cannot “see” scripts that were compiled while the debugging interface was inactive. So if you turn off start-up initialization Venkman will always start with an empty file list. You will need to reload the pages you want to debug to see something. Even with start-up initialization some XPCOM components will remain invisible. This is being caused by bug 480765 – I hope that the patch there lands soon and Venkman is adjusted as well then.


  • johnjbarton

    Firebug 1.4 has an auto-suspend which we use to reduce the overhead of the ‘jsd’ layer underlying both Venkman and Firebug. Currently we are ‘pause/unpause’ jsd but I think we could turn it ‘on’ and ‘off’. I don’t actually know how performance varies with these settings; Firebug layers more work on top of what jsd & venkman already do so we had to implement suspend for our own code.

    Wladimir Palant

    It seems that you get at least the same performance cost as soon as you install Chromebug. It will flip Firebug’s filterSystemURLs pref which effectively means that Firebug always turns on the debugger at startup. And it stays permanently on which has the impact on performance that I describe here – regardless of whether Firebug is actually doing anything with the debugger. That effect stays even after you uninstall Chromebug.

  • johnjbarton

    Chromebug does not use Firebug’s suspend/resume. jsd needs to be on during startup to gather information on the components as they are compiled. After that suspend/resume could be used. I’ve not tried to do this since I imagined most uses of Chromebug will be for debugging not running the browser.