<< EarlyBlue and LCARStrek for SeaMonkey 2.0 Alpha 3 | The roads I take... | Integration eines Magento-2-Webshops mit FreeFinance und selbstgebautem Warenmanagement >>

Impressed With Non-JIT JS Speedups

Prompted by Wladmimir's post on the perf cost of venkman, I filed a bug on getting rid of that cost in SeaMonkey, either by fixing the actual problem or not enabling whatever causes this slowdown - even if (what I don't hope) it would mean not shipping venkman in the worst case.

With JS perf tests being the number one rocks/sucks meter of browsers right now, esp. with advanced user and web developers, who are a very major part of our target audience, we cannot afford to look worse than Firefox in SunSpider and similar benchmarks.

But here's the real surprise moment I had in all that:

To get some useful data of what the penalty is and if there a significant difference to the old SeaMonkey 1.1.x series in that, I did run SunSpider in a current comm-central/mozilla-1.9.1-based SeaMonkey 2.0b1pre build and a mozilla-1.8.1-based SeaMonkey 1.1.16pre build:

SeaMonkey 1.1.16pre: 15719.8ms +/- 1.5%

SeaMonkey 2.0b1pre (venkman disabled, JIT.content disabled!): 2751.6ms +/- 2.1%

Now that's impressive. This is interpreted code, without just-in-time compilation, and it's still very significantly faster than the old 1.8.1 JS engine. Good work, SpiderMonkey developers!
And yes, this are results on the same machine, under the same testing conditions, with mostly empty testing profiles.

With JIT, we're even faster, of course:

SeaMonkey 2.0b1pre (venkman disabled): 1954.8ms +/- 9.4%

Unfortunately, the penalty of just having venkman enabled is real though, resulting in a ~17% slowdown in my tests:

SeaMonkey 2.0b1pre (default config): 2289.8ms +/- 10.7%

We really need to find a solution for that, ideally so that we can give our users a JS debugger available in the suite by default but still give everyone at any time where he doesn't want to actually debug JS code the best possible performance.

I continue to be impressed with the work the SpiderMonkey/TraceMonkey team did, though, the current 1.9.1 JS engine is already so much better than what we had in 1.8.1, and it's not even finished up yet.

Entry written by KaiRo and posted on March 14th, 2009 18:39 | Tags: JavaScript, Mozilla, SeaMonkey | 5 comments


  • Home of KaiRo: Weekly Status Report, W11/2009 (Pingback)
  • [Gecko 1.9.1] Adblock+ teilweise kaputt - Seite 2 | hilpers (Pingback)
  • Comments



    from ru

    As for me I've deleted Venkman manually in zip installation of SM last 2 years. :)
    I am not developer so I don't need JS debugger at all. And I am right as I see. :)
    2009-03-14 22:29


    from usa

    Venkman and perf
    Yep, goes for TB trunk also.
    Somewhere around 16% perf boost after disabling the extension.
    Who would have thought that an inactive extension could have this impact.
    2009-03-15 03:43



    Just note that 1) my point here is the improvements in interpreted JavaScript between 1.8.1 and 1.9.1 which are really impressive and 2) I'm pretty sure the culprit of that regression with venkman can be found and eliminated, and then we can happily work with venkman enabled and good performance.
    2009-03-15 14:17


    I don't understand. Isn't Venkman the JavaScript debugger? How does that affect JS speed at all when you're not debugging?
    2009-03-15 20:30



    It's actually starting some part of the debugging when it's just installed and nobody started debugging actively yet, as else it wouldn't notice a number of things loaded before the venkman window itself.
    We're discussing solutions in the bug mentioned, and I'm sure we will find some.
    2009-03-16 20:39

    Add comment