<< 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.

Beitrag geschrieben von KaiRo und gepostet am 14. März 2009 18:39 | Tags: JavaScript, Mozilla, SeaMonkey | 5 Kommentare

TrackBack/Pingback

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

    AutorBeitrag

    Vladimir

    aus ru

    zitieren
    Venkman
    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. :)
    14.03.2009 22:29

    JoeS

    aus usa

    zitieren
    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.
    15.03.2009 03:43

    KaiRo

    Webmaster

    zitieren
    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.
    15.03.2009 14:17

    Keith

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

    KaiRo

    Webmaster

    zitieren
    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.
    16.03.2009 20:39

    Kommentar hinzufügen