Mozilla adds new baseline compiler to Firefox Nightly

Martin Brinkmann
Apr 6, 2013

I can't really say it any other way but I think that Mozilla managed to turn the Firefox browser around in a rather short period of time from a slow browser that was highly customizable to a browser that does not really have to hide behind the speed and performance of Google's Chrome browser any more. In fact, Mozilla managed to beat Google in many areas where Chrome once reigned supreme or at least closed the gap. That's not to say that Chrome is not still in the lead in some areas, as the latest HTML5 test shows for instance, but the gap is closing fast.

Google on the other hand seems to fight with Chrome becoming sluggish and criticism seems to have increased in recent time. The recent announcement to create the WebKit fork Blink may be one of the ways that Google hopes will resolve many of the issues of the browser.

Mozilla, after launching the OdinMonkey component in Nightly versions of Firefox in March has added a new baseline compiler to Firefox Nightly that improves the browsers performance in the company's own Kraken benchmark and Google's Octane benchmark by 5-10%.

What may be even more important is that it is also the base for future improvements to the browser. Mozilla has hopes to reduce the memory usage of the browser and use it to speed up the implementation of optimizations in the browser.
firefox google benchmark

Firefox up to this point used two Just In Time (JIT) compilers: Jaegermonkey and IonMonkey.

Jaeger is a general purpose JIT that is “pretty fast”, and Ion is a powerful optimizing JIT that’s “really fast”.

Jaegermonkey is currently being used as a stopgap baseline compiler for IonMonkey. The problem here is that it was never designed for that job. That's why Mozilla created a new baseline compiler that has been designed from the ground up with IonMonkey in mind.

You can read a detailed explanation of why this has become necessary at the official Mozilla blog.

Interesting from a general user perspective is the outlook that Mozilla gives in the same blog post. Users can expect "significant memory savings", "performance improvements" and "better optimizations of high level features".


Tutorials & Tips

Previous Post: «
Next Post: «


  1. Anon said on July 29, 2013 at 6:06 am

    I hate chrome’s scrolling, it’s universally very annoying and not smooth at all. It is by far the #1 reason I don’t prefer it. Firefox’s smooth scrolling is not perfect, but it’s at least 5 times closer smoother and more responsive than chrome’s. Except that firefox has more specific scrolling issues.. often until an active page has been scrolled top to bottom, the scrolling is abysmal, then it fixes itself and becomes ultra smooth again. Exception #2 is the add-on page.. it seems to scroll horribly no matter what.

  2. Caspy7 said on April 6, 2013 at 2:10 pm

    Over the past year+ Mozilla has been working hard on memory and responsiveness. (Firefox now beats the other major browsers for memory usage.)
    The Javascript speed in comparison to Chrome hasn’t been horrible – a matter of milliseconds separating most of the browsers in benchmarks is not noticeable to most users – but the browser responsiveness is really what was killing them. Small pauses in animations & scrolling (jank), short freezes, unresponsive times, slow startup, not-quick tab opening, etc, etc; all contributed to making Firefox feel and be slow while Chrome was winning in all those areas.

    On top of now being on par with Chrome’s Javascript speed, all those areas of responsiveness have improved vastly. (So if you left Firefox for being slow, it might be a good time to give it another go.)

    P.S. I recommend starting with a profile reset for optimum goodness:

  3. Compuitguy said on April 6, 2013 at 12:52 pm

    for now pdf.js is supposed to give basic a function which most users asked for

    and a lot of bugs are fixed now in the coming versions

    1. Compuitguy said on April 6, 2013 at 1:01 pm

      and for me it is enough

    2. Compuitguy said on April 6, 2013 at 12:57 pm

      * a basic function

  4. fokka said on April 6, 2013 at 11:52 am

    i’m not a heavy pdf-user and personally like the integration of pdf.js into the browser. what is a no-go tough is the stupid bar popping up on top notifying me that there may be problems with the display of the file. yeah, i know the function is still quite “beta”, can you please stop nagging now?

  5. JBDaddy said on April 6, 2013 at 8:40 am

    They have also managed to break support for PDFs in late versions. I discovered yesterday that version 19 changed (appears to have been silently, without user option) default handling for PDFs to display them in a new PDF.js driven component – which mishandles fillable fields, some fonts, some images and other features of PDFs.
    Now while a PDF may display correctly in Adobe Reader, Google Chrome, Foxit, Sumatra, etc… Firefox shows it missing data.

    It’s incredible that this change was made without adequate testing or more notification to users. Imagine companies around the world having to field calls from angry users that the PDFs used to document important data forms, etc are now missing data – only to find out it’s because of the browser that end user is using, not a programming, document maintenance or other bug the company could be responsible for. That’s the situation I’m in, and I’m annoyed as hell with Firefox over it.

    1. city_zen said on April 6, 2013 at 1:46 pm

      You can go back to the previous way of handling pdf files quite simply:

Leave a Reply

Check the box to consent to your data being stored in line with the guidelines set out in our privacy policy

We love comments and welcome thoughtful and civilized discussion. Rudeness and personal attacks will not be tolerated. Please stay on-topic.
Please note that your comment may not appear immediately after you post it.