JavaScript speedups in Firefox 3.6

This post was written by David Mandelin who works on Mozilla’s JavaScript team.

Firefox 3.5 introduced TraceMonkey, our new JavaScript engine that traces loops and JIT compiles them to native (x86/ARM) code. Many JavaScript programs ran 3-4x faster in TraceMonkey compared to Firefox 3. (See our previous article for technical details.)

For JavaScript performance in Firefox 3.6, we focused on the areas that we thought needed further improvement the most:

  • Some JavaScript code was not trace-compiled in Firefox 3.5. Tracing was disabled by default for Firefox UI JavaScript and add-on JavaScript, so those programs did not benefit from tracing. Also, many advanced JavaScript features were not trace-compiled. For Firefox 3.6, we wanted to trace more programs and more JS features.
  • Animations coded with JavaScript were often choppy because of garbage collection pauses. We wanted to improve GC performance to make pauses shorter and animations smoother.

In this article, I’ll explain the most important JS performance improvements that come with Firefox 3.6. I’ll focus on listing what kinds of JS code get faster, including sample programs that show the improvements Fx3.6 makes over Fx3.5.

JIT for Browser UI JavaScript

Firefox runs JavaScript code in one of two contexts:content and chrome (no relation to Google Chrome). JavaScript that is part of web content runs in a content context. JavaScript that is part of the browser UI or browser add-ons runs in a chrome context and has extra privileges. For example, chrome JS can alter the main browser UI, but content JS is not allowed to.

The TraceMonkey JIT can be enabled or disabled separately for content and chrome JS using about:config. Because bugs affecting chrome JS are a greater risk for security and reliability, in Firefox 3.5 we chose to disable the JIT for chrome JS by default. After extensive testing, we’ve decide to enable the JIT for chrome JS by default, something we did not have time to fully investigate for Fx3.5. Turning on the JIT for chrome should make the JS behind the Firefox UI and add-ons run faster. This difference is probably not very noticeable for general browser usage, because the UI was designed and coded to perform well with the older JS engines. The difference should be more noticeable for add-ons that do heavy JS computation.


Fx3.5 Default

Fx3.6 Default




about:config options for the JIT

Garbage Collector Performance

JavaScript is a garbage-collected language, so periodically the JavaScript engine must reclaim unused memory. Our garbage collector (GC) pauses all JavaScript programs while it works. This is fine as long as the pauses are “short”. But if the pauses are even a little too long, they can make animations jerky. Animations need to run at 30-60 frames per second to look smooth, which means it should take no longer than 17-33 ms to render one frame. Thus, GC pauses longer than 40 ms cause jerkiness, while pauses under 10 ms should be almost unnoticeable. In Firefox 3.5, pause times were noticeably long, and JavaScript animations are increasingly common on the web, so reducing pause times was a major goal for JavaScript in Firefox 3.6.

Demo: GC Pauses and Animation

The spinning dial animation shown here illustrates pause times. Besides animating the dial, this demo creates one million 100-character strings per second, so it requires frequent GC. The frame delay meter gives the average time between frames in milliseconds. The estimated GC delay meter gives the average estimated GC delay, based on the assumption that if a frame has a delay of 1.7 times the average delay or more, then exactly one GC ran during that frame. (This procedure may not be valid for other browsers, so it is not valid for comparing different browsers. Note also that the GC time also depends on other live JavaScript sessions, so for a direct comparison of two browsers, have the same tabs open in each.) On my machine, I get an estimated GC delay of about 80 ms in Fx3.5, but only 30 ms in Fx3.6.

But it’s a lot easier to see the difference by opening the demo in Fx3.5, watching it a bit, and then trying it in Fx3.6.
In Fx3.5, I see frequent pauses and the animation looks noticeably jerky. In Fx3.6, it looks pretty smooth, and it’s hard for me even to tell exactly when the GC is running.

How Fx3.6 does it better. We’ve made many improvements to the garbage collector and memory allocator. I want to give a little more technical details on the big two changes that really cut our pause times.

First, we noticed that a large fraction of the pause time was spent calling free to reclaim the unused memory. We can’t do much to make freeing memory faster, but we realized we could do it on a separate thread. In Fx3.6, the main JS thread simply adds unused memory chunks to a queue, and another thread frees them during idle time or on a separate processor. This means machines with 2 or more cores will benefit more from this change. But even when one core, freeing might be delayed to an idle time when it will not affect scripts.

Second, we knew that in Fx3.5 running GC clears out all the native code compiled by the JIT as well as some other caches that speed up JS. The reason is that the tracing JIT and GC did not know about each other, so if the GC ran, it might reclaim objects being used by a compiled trace. The result was that immediately after a GC, JS ran a bit slower as the caches and compiled traces were built back up. This would be experienced as either an extended GC pause or a brief hiccup of slow animation right after the GC pause. In Fx3.6, we taught the GC and the JIT to work together, and now the GC does not clear caches or wipe out native code, so it resumes running normally right after GC.

Tracing More JavaScript Constructs

In my article on TraceMonkey for the Fx3.5 release, I noted that certain code constructs, such as the arguments object, were not traced and did not get performance improvements from the JIT. A major goal for JS in Fx3.6 was to trace more stuff, so more programs can run faster. We do trace more stuff now, in particular:

  • DOM Properties. DOM objects are special and harder for the trace compiler to work with. For Fx3.5, we implemented tracing of DOM methods, but not DOM properties. Now we trace DOM properties (and other “native” C++ getters and setters) as well. We still do not trace scripted getters and setters.
  • Closures. Fx3.5 traced only a few operations involving closures (by which I mean functions that refer to variables defined in lexically enclosing functions). Fx3.6 can trace more programs that use closures. The main operation that is still not traced yet is creating an anonymous function that modifies closure variables. But calling such a function and actually writing to the closure variables are traced.
  • arguments. We now trace most common uses of the arguments keyword. “Exotic” uses, such as setting elements of arguments, are not traced.
  • switch. We have improved performance when tracing switch statements that use densely packed numeric case labels. These are particularly important for emulators and VMs.

These improvements are particularly important for jQuery and Dromaeo, which heavily use arguments, closures, and the DOM. I suspect many other complex JavaScript applications will also benefit. For example, we recently heard from the author that this R-tree library performs much better in Fx3.6.

Here is a pair of demos of new things we trace. The first sets a DOM property in a loop. The second calls a sum function implemented with arguments I get a speedup of about 2x for both of them in Fx3.6 vs. Fx3.5.

Demo: Fx3.6 Tracing DOM properties and arguments

DOM Property Set:

Sum using arguments:

String and RegExp Improvements

Fx3.6 includes several improvements to string and regular expression performance. For example, the regexp JIT compiler now supports a larger class of regular expressions, including the ever-popular w+. We also made some of our basic operations faster, like indexOf, match, and search. Finally, we made concatenating sequences of several strings inside a function (a common operation in building up HTML or other kinds of textual output) much faster.

Technical aside on how we made string concatenation faster: The C++ function that concatenates two strings S1 and S2 does this: Allocate a buffer big enough to hold the result, then copy the characters of S1 and S2 into the buffer. To concatenate more than two strings, as in JS s + "foo" + t, Fx3.5 simply concatenates two at a time from left to right.

Using the Fx3.5 algorithm, to concatenate N strings each of length K, we need to do N-1 memory allocations, and all but one of them are for temporary strings. Worse, the first two input strings are copied N-1 times, the next one is copied N-2 times, and so on. The total number of characters copied is K(N-1)(N+2)/2, which is O(N^2).

Clearly, we can do a lot better. The minimum work we can do is to copy each input string exactly once to the output string, for a total of KN characters copied. Fx3.6 achieves this by detecting sequences of concatenation in JS programs and combining the entire sequence into one operation that uses the optimal algorithm.

Here are a few string benchmarks you can try that are faster in Fx3.6:

Demo: Fx3.6 String Operations




Build HTML:

Final Thoughts and Next Steps

We also made a lot of little improvements that don't fit into the big categories above. Most importantly, Adobe, Mozilla, Intel, Sun, and other contributors continue to improve nanojit, the compiler back-end used by TraceMonkey. We have improved its use of memory, made trace recording and compiling faster, and also improved the speed of the generated native code. A better nanojit gives a boost to all JS that runs in the JIT.

There are two big items that didn't make the cut for Fx3.6, but will be in the next version of Firefox and are already available in nightly builds:

  • JITting recursion. Recursive code, like explicit looping code, is likely to be hot code, so it should be JITted. Nightly builds JIT directly recursive functions. Mutual recursion (g calls f calls g) is not traced yet.
  • AMD x64 nanojit backend. Nanojit now has a backend that generates AMD x64 code, which gives the possibility of better performance on that plaform.

And if you try a nightly build, you'll find that many of these demos are already even faster than in Fx3.6!

About Alix Franquet

More articles by Alix Franquet…


  1. fabrice

    Great post !

    Is there any tool available to check if an extension’s code is being traced or not ?

    January 13th, 2010 at 10:37

    1. Dave Mandelin

      There is a tool we use for that, TraceVis, which I blogged about earlier on my personal blog, but it’s not enabled in standard browser builds. We want to get it enabled, possibly in a special build with an extension, but we haven’t had the time to do that. If you’re brave, it’s possible to patch the source code and then build a browser that would have TraceVis in it. Email me for help if you want to try that.

      January 13th, 2010 at 18:17

  2. Nice Try

    Nice try, but Chrome and V8 still significantly outperform Tracemonkey. In addition, I still see animation pauses for garbage collection, whereas, it’s completely smooth in Chrome.

    January 13th, 2010 at 10:47

  3. sep332

    x64 JIT? Is this feature available in Windows nightlies, or do I have to manually build for 64-bit Windows?

    January 13th, 2010 at 10:51

  4. Zorkzero

    Just tried the benchmark on . Firefox 3.6rc1 fails when “Deleting 1k elements..” with the following message:
    Error: b is undefined
    Line: 689

    Firefox 3.5.7 completes all test just fine. That’s on Windows XP SP3.

    January 13th, 2010 at 11:17

    1. Dave Mandelin

      Which exact page do you get that error on? I clicked “Benchmark”, which led to It ran to completion for me without JS errors on Vista with 3.6rc1.

      January 13th, 2010 at 18:22

      1. Zorkzero

        I get it on . I have even created a new, clean profile and I still get the same error.

        When I start with “-safe-mode” the benchmarks completes fine. So it must be one of these extensions: “Java Console 6.0.18”, “Java Quick Starter 1.0” “Microsoft .NET Framework Assistant”. Even if I disable all these extensions I still get the error. I can’t uninstall any of them, the “Uninstall” button is grayed out.

        January 14th, 2010 at 07:45

        1. Jamie Penney

          I can confirm this fails for me with the same error using Firefox 3.6 on 32 bit Windows 7.

          January 24th, 2010 at 14:16

        2. Max

          On 3.6 that test never finishes for me. It just says “Deleting 1k items”. On chrome it runs to completion.

          January 24th, 2010 at 15:14

  5. Ted Mielczarek

    sep332: We do not currently have 64-bit Windows nightlies. Our Windows nightlies are 32-bit, and use the x86 JIT backend.

    January 13th, 2010 at 11:42

  6. Boris

    sep332, you’d need to be using a 64-bit build to use it. I don’t think we currently have 64-bit Windows nightlies.

    January 13th, 2010 at 12:57

  7. TNO

    In regards to regular expressions, the tokens “s”, “S”, “.”, “^”, and “$” are Unicode aware. Is there an optimization in place that can recognize whether a string actually contains any non-ASCII characters? If not, couldn’t this ability potentially allow the use of far fewer character comparisons?

    January 13th, 2010 at 13:58

  8. Alex Vincent

    I’d suggest you look at your post on – the text is overlapping with a couple other posts there…

    January 13th, 2010 at 15:14

    1. Alix Franquet

      Alex: thanks for letting us know! Looking into it now.

      January 13th, 2010 at 16:13

  9. Drazick

    When will FF offer the same performance as Safari, Chrome and lately even Opera?


    January 13th, 2010 at 17:16

  10. David

    I’m getting Est GC delay: 2255ms using FF3.5 64bit on Ubuntu. Not sure if the slowdown is because of XULRunner’s crap performance on Linux or if it’s purely because it’s using the old JS engine. Will FF 3.6 64 have tracemonkey?

    Also, you’ll want to fix the email validation on this form. Doesn’t work with valid email addresses like

    January 13th, 2010 at 17:59

  11. Question

    nightly 20091213 vs chrome3
    gc delay:100ms vs 6ms

    January 13th, 2010 at 22:31

  12. Transcontinental

    Frankly – I’ve compared speed of page layout (including heavily scripted pages) with JIT (chrome & content) on FF 3.6 RC and Google Chrome, and I really perceive no difference. I did with Firefox 3.5.7 (JIT content AND chrome as well with no problem), but Firefox 3.6 RC is really – objectively – very fast, and smooth. I admit computing to the milliseconds may seflect unperceived differences but, once again, not noticeable as far as I’m concerned. One last point: in Google’s Chrome latest beta, layout velocity seemed somewhat random as compared to a TraceMonkey’s more regular performance.

    January 14th, 2010 at 00:47

  13. Gerv

    Have you done those GC timing measurements on all platforms? On my
    Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2) Gecko/20100105 Firefox/3.6
    (3.6-latest on Ubuntu 9.10, on an IBM Thinkpad X200), the average GC delay for the demo above is 75ms after a restart. And the animation is noticeably jerky when there’s a GC.

    However, when I first came to this page and tried that demo, the time was consistently 600ms over a period of about a minute! I was wondering why my Firefox was experiencing frequent mini-hangs. I did have some other tabs open, although nothing that seemed particularly active. This sort of performance degradation happens to me a lot; I have to restart Firefox frequently. How do I go about tracking down what is causing it?

    January 14th, 2010 at 04:10

  14. Neil Rashbrook

    The code blocks always show in the syndicated version on Planet, but the height limit still takes effect, which makes the code overflow over the following posts…

    January 14th, 2010 at 04:19

  15. Ciprian Mustiata

    Hello. Pauses are really noticeable on 3.6 builds but probably I miss something (I have a 2 GHz+ CPU and pauses are 75 ms on my machine). I found two ways to handle small pauses and both go with the phrase: collect small heaps:
    – use a generational GC (I know that this is hard to be made, but the solution will make to adjust the latest generation size to make pauses predictible of around 10 ms) instead collecting all heap. For major collection that will eventually happen, that could happeneither using generations with predictible sizes (look for train collection algorithm, used in older java implementations), or you can do a bleeding edge algorithm (like G1) which will always collect the bigger blocks in a specified time. The second may be good for having predictible pauses.
    – separate heaps per components: tabs, chrome framework. This will make that the search space for dead objects smaller. Separating heaps per components will make easier to remove/add a new heap in overhead marks. Anyway, JS can access separate heaps and should be some marshaling involved.
    I know that both things are easier to be spoken than to be made, but in the same moment I have to say those problems, that maybe someone will find a proper solution with minimal impact on user experience.
    The TraceMonkey JIT I think that is really capable today, even is not neck on neck with other implementations (2x slower). But I think that many of those benchmarks do not expose in fact that 2x speed slower is in fact 20 times faster than was 2 years earlier.
    Great job guys!

    January 14th, 2010 at 04:32

  16. Fab

    IE7: DOM Property Set: 88935 ms
    FF3.6: DOM Property Set: 55 ms

    We won’t be able to do anything nice while other browsers have such bad performance.

    January 14th, 2010 at 07:01

  17. Boris

    Actually, the “DOM property set” test is not actually testing the DOM property stuff, since there is no “x” DOM property on HTMLSpanElement. It’s just testing expandos (still useful, but not what jorendorff’s patches aimed to fix).

    January 14th, 2010 at 09:07

  18. Boris

    Zorkzero, safe mode disables the jit, so the bug goes away.

    For what it’s worth, I can reproduce the bug and filed on it. It’s now blocking 3.6 release.

    January 14th, 2010 at 09:11

  19. Kelly Clowers

    Just tried the tests here with SeaMonkey 2.0.3pre (Gecko and FF3.7 20100112 (both 64 bit on Linux).
    Very nice speed increases. The animation still had some jerks, though, with ~80 ms delay.

    @fab IE 8 is much better (and IE 6 and 7 share is falling in favor of 8), and IE 9 builds are much better again, being in the same ballpark as everyone else.

    January 14th, 2010 at 20:02

  20. Mark

    I just tried the gc jerkiness test in 3.6 and it’s still easily noticeable when gc occurs (skips 1/4 of circle gc delay 70-95 ms) when many tabs open (30).
    This is on Linux.

    January 16th, 2010 at 07:59

  21. Ricardo

    Got 85ms for GC on 3.6/Win XP, clear delay and jerkyness. Nothing new.

    January 16th, 2010 at 12:23

  22. nemo

    Ricardo, are you using Firebug?
    Might want to disable the addon before trying out this page.

    January 19th, 2010 at 11:39

  23. Hanster


    January 19th, 2010 at 19:39

  24. mawrya

    There should be a warning at the top of this post – Firebug interferes with the JIT, particularly versions before 1.5

    Considering that developers are the most likely to be reading this and also the most likely to have firebug installed, they might end up making flaky comparisons between Firefox and other browsers or coming to other conclusions because, unbeknownst to them, Firebug has completely disabled JIT.

    January 19th, 2010 at 21:56

  25. […] är inte en vanlig underhållsversion utan sägs vara mycket snabbare än sin föregångare. På den här sidan kan du läsa om en lång artikel (men också mycket teknisk) som visar de framsteg som gjorts i […]

    January 20th, 2010 at 23:24

  26. […] Speed Improvements – TraceMonkey, the fast JS engine has gotten some tweaks to improve performance even further. Seeking in <video/> is now much faster than it was in […]

    January 21st, 2010 at 12:13

  27. […] la respuesta global del navegador tanto abriendo pestañas como reduciendo el tiempo de arranque. Firefox 3.6 mejora el rendimiento en un 20% frente a Firefox […]

    January 21st, 2010 at 12:49

  28. […] for Personas, lightweight themes that can be installed without restarting the browser, and adds further performance improvements to the new Tracemonkey Javascript engine. One of the major goals of the release was to improve startup time and general UI responsiveness, […]

    January 21st, 2010 at 13:22

  29. […] ran 3-4x faster in TraceMonkey compared to Firefox 3,” writes David Mandelin, a software engineer working on Mozilla’s JavaScript team. “For […]

    January 21st, 2010 at 14:01

  30. Sun

    I’m almost done moving over to Chrome. Just need bookmark sync (which Chrome has in the beta) but I want to use Xmarks instead. We thought Firefox was great for a few years, but Chrome has been kicking your ass. I hope you guys can improve your speed so we stay with you.

    January 21st, 2010 at 14:25

  31. […] for Personas, lightweight themes that can be installed without restarting the browser, and adds further performance improvements to the new Tracemonkey Javascript engine. One of the major goals of the release was to improve startup time and general UI responsiveness, […]

    January 21st, 2010 at 14:49

  32. […] Javascript Performansı: Javascript performansında hızlandırmaya gidilmiş. Ayrıntılı bilgi için tıklayınız. […]

    January 21st, 2010 at 15:11

  33. […] the work done to prevent crashes with third party software.  There are also enhancements like improved JavaScript performance and optimizations to speed up everyday Web tasks to make web applications snappier.  However, what […]

    January 21st, 2010 at 16:01

  34. […] un 20% más rápido que Firefox 3.5, incluyendo nuevos trazados para códigos JavaScript (tienes un artículo muy técnico en la página de Hacks en inglés). Junto a esta mejora, el navegador responde de forma más fluida y tiene un tiempo de […]

    January 21st, 2010 at 18:20

  35. Wiritpol

    Firefox 3.6 does not support these ICC profiles version 4

    January 21st, 2010 at 20:07

  36. mynthon

    gc delay in fx3.5: ~100ms
    gc delay in fx3.6: ~140ms

    i don’t see improvement.

    January 22nd, 2010 at 11:59

  37. […] Lockdown, which locks out Firefox add-ons without explicit user permission. In addition, they made several improvements to the TraceMonkey JavaScript engine for improved / faster video performance, along with many other […]

    January 22nd, 2010 at 16:19

  38. Marko Macek

    I tried it again with 3.6 final release, the delay is now 40-45 ms (still 30+ tabs open).

    January 23rd, 2010 at 05:08

  39. Mark Holton

    Please keep pushing forward (and sharing these insights).
    With great appeciation-

    January 24th, 2010 at 01:23

  40. […] David Mandelin, who works on Mozilla’s JavaScript team, has posted technical details on Firefox 3.6’s JavaScript improvements on the blog. […]

    January 24th, 2010 at 02:01

  41. […] The new version of Firefox, 3.6, is about 15% faster than Firefox 3.5, according to tests run by Computerworld. Firefox now renders JavaScript three times faster than Opera 10 and about four times faster than IE8. This data places Firefox as the 3rd fastest browser on the net – after Safari and Chrome. If you want to read more about the Java speed-ups on Firefox, there’s a lot of info here. […]

    January 24th, 2010 at 03:08

  42. […] full post on Hacker News If you enjoyed this article, please consider sharing it! Tagged with: Firefox […]

    January 24th, 2010 at 06:47

  43. gwenhwyfaer

    Don’t have 3.5 to test. But under FF 3.6, WinXP sp2, Duron 1600 with 512MB RAM and shared video, I get GC pauses of 280-320ms.

    (Anyone telling me to upgrade my machine is welcome to give me some money with which to do so.)

    January 24th, 2010 at 06:51

    1. gwenhwyfaer

      (Please reparent the above comment.)

      January 24th, 2010 at 06:52

  44. Jimboooo!

    Frame delay: 28
    GC delay: 416
    Jerky as hell (couldn’t tell which way the line was spinning)

    That’s on Linux with no other apps/tabs open. Why /is/ Firefox performance so bad on Linux? Chrome rendered the line perfectly smoothly.

    January 24th, 2010 at 08:24

    1. David

      Thunderbird is also sluggish on Linux, so it’s probably because of XULRunner having poor performance.

      January 25th, 2010 at 17:38

  45. […] David Mandelin, who works on Mozilla’s JavaScript team, has posted technical details on Firefox 3.6’s JavaScript improvements on the blog. […]

    January 24th, 2010 at 08:50

  46. […] David Mandelin, who works on Mozilla’s JavaScript team, has posted technical details on Firefox 3.6’s JavaScript improvements on the blog. […]

    January 24th, 2010 at 12:20

  47. […] Chrome. For those not feeling the love, here are the nitty gritty details of FF 3.6s speedup: JavaScript speedups in Firefox 3.6 ✩ Mozilla Hacks – the Web developer blog Make sure that the following options are true in about:config (although they are true by default […]

    January 24th, 2010 at 15:34

  48. Mic

    As I develop a web app, I live most of my day within a FF window.
    I was a bit reluctant to move to 3.6, as in the past some releases broke my development setup.

    I moved first to Firebug 1.5, it was immediately better.
    But installing the 3.6 radically improved the response time. Every operation seems now immediate.

    A big thank you for your work, you made mine way faster as from today.

    January 24th, 2010 at 16:30

  49. […] Salah satu anggota tim yang mengerjakan JavaScript Mozilla, David Mandelin, memosting detail teknis pada pengembangan JavaScript Firefox 3.6, di blog beralamat […]

    January 25th, 2010 at 07:16

  50. […] David Mandelin, who works on Mozilla’s JavaScript team, has posted technical details on Firefox 3.6’s JavaScript improvements on the blog. […]

    January 25th, 2010 at 07:57

  51. onur

    Firefox 3.6 does not support these ICC profiles version 4

    January 25th, 2010 at 12:00

  52. Dimitrs

    May I, humbly, suggest an option to just JIT *everything* instead of burning cycles analyzing code paths? I think Chrome works this way.

    January 26th, 2010 at 06:50

  53. […] 3.6 was released last week, representing a lot of work from a whole lot of people. JavaScript performance is faster still than the already fast 3.5 and there have been a number of other areas of the UI […]

    January 26th, 2010 at 07:01

  54. tsphand1

    I need more speed up

    mozilla can build x64 version…………
    when it done?

    January 28th, 2010 at 01:49

  55. Chris

    Firefox 3.6 clean start
    Frame Delay: 16
    GC Delay: 74

    Chrome 4 clean start
    Frame Delay: 9
    GC Delay: 16

    Methinks Mozilla have a way to go with this one.

    January 28th, 2010 at 14:54

  56. Vijay Rayapati

    Awesome, when we will have threaded JS execution in FF like similar thing in Google Gears.

    January 29th, 2010 at 04:10

    1. Sasha Chedygov

      It already exists. Check out the Web Workers API.

      January 30th, 2010 at 14:13

  57. F

    Frame Delay: 13
    GC Delay: 143

    Meh, i dont see the difference

    January 30th, 2010 at 08:31

  58. default

    I think it’s very sad that the x86_64 nanojit is still not available in Firefox 3.6. I regularly test trunk builds and it’s been working well for me for *months* already.

    Keep in mind that on Unix, i.e. Linux/FreeBSD, a native, 64 bit Firefox is the default on x86_64 systems!

    January 31st, 2010 at 12:04

  59. Pascal

    uh, quite interesting: did just for fun some comparison between fx3.6 and chrome and even while i have about 100 tabs in fx open it is still faster in the string section (about 3 times!)

    February 2nd, 2010 at 08:46

  60. bleh

    3.6 seems very fast and smooth compared to 3.5. I have chrome 4 beta also installed and it’s not as fast as I remember. They seem the same to me but Chrome does not have NoScript. Chrome with extensions has really slowed it down. Keep moving on FF, its making progress.

    February 2nd, 2010 at 20:35

    1. Ziru

      The good thing about Chrome is that it is not difficult to figure out which extension slows the browser down. Users can therefore easily disable the buggy extension. For FF, the most-often recommendation from the Mozilla forum is to switch to the safe-mode, disable all the extensions, and enable them one by one.

      March 1st, 2010 at 11:36

      1. raj

        I have tried both chrome and firefox.You have more plugins choice for firefox.These plugins make firefox more usable and reliable.

        March 15th, 2011 at 05:55

  61. nick

    Those string operations in the last box run significantly faster in firefox than in Chrome, and I have the latest build of both. However, the first two tests are faster in chrome.

    I get an estimated GC delay of 91 ms! Chrome seems to consume a lot more system resources to get the 10 ms score on the same test. My computer is quite old though, so maybe I can’t win.

    May 8th, 2010 at 13:34

  62. Gary

    Well, I think I’ve just about had it with Firefox… unless someone has a suggestion to help me.

    In my experience, the GC hesitations in Firefox 3.x have become much more common. It’s mostly prominent with watching videos. Yes, even after a video has cached, it will experience momentary pauses every 15-20 seconds, so it is nothing to do with streaming. Clearing the cache doesn’t seem to help. A fresh reboot will lessen the effect, but after loading a few web pages and running a few videos, the hesitations become quite noticeable.

    I ran the GC pause animation in Firefox, and I get on average GC delays of 59ms, frame delays of 17ms. The second hand repeatedly pauses once or twice with EVERY rotation.

    I ran the GC pause animation in Google Chrome, and I get on average GC delays of 12ms and frame delays of 7ms. I get a clean sweep of the second hand, no pauses whatsoever.

    I spent hours searching around the Internet, trying to find information about these pauses that I’ve experienced, until finally finding this page. The results tell me that I’m better off with Google Chrome… unless there is some special update I can apply to fix the GC performance in Firefox?

    May 27th, 2010 at 10:27

    1. Gary

      NOTE: My stated GC delay in Firefox is understated. Rerunning the animation shows a wild swing of results, much higher than I originally found. As of my last run, it started out in the mid 50’s, then continued to rise with each cycle of the second hand, bumping up to over 100ms, then leveling off in the mid 90’s. I’m not surprised, given the behavior I’ve experienced with it…

      May 27th, 2010 at 10:38

    2. Christopher Blizzard

      Gary –

      Firefox does have a browser-wide GC, which does cause pauses across the entire browser and ends up running pretty often, especially if you have a lot of tabs open.

      For Firefox 4 we’re planning to have per-page GC implemented which will give us most of the benefit of the per-process model that Chrome enjoys.

      Note that these tests are built to trigger the GC in Firefox. Chrome might not even run the GC at all running these tests. (In fact, there’s a big fat warning in the post that says: “This procedure may not be valid for other browsers, so it is not valid for comparing different browsers.”) So keep that in mind as well.

      So agreed that GC pauses suck, we’re going to have something for Firefox 4 and when we move to a multi-process model we’ll be in even better shape.

      May 27th, 2010 at 10:42

  63. Gary

    Thanks for the rapid reply, Christopher (hadn’t expected it so fast, so I didn’t return right away). :-)

    My bad… I didn’t even realize that Chrome is based on the WebKit layout engine and application framework, so it doesn’t have anything in common with Mozilla.

    I did conduct my own test, of performing the same browsing activities in both Chrome and Firefox after a reboot to clear out any used up memory. After a while, I began to notice how video response in Chrome was better. Firefox would start to slip into this periodic hesitation/pause during playback.

    I did not see this problem in earlier version of Firefox. I can’t recall when it began to surface. In any case, was it a change in the operating model that started it? Or was it always there, just took a few other changes to help reveal it?

    Chrome has some appealing attributes to it, like the small real estate usage at the top that allows for a greater viewing area in each tab. And it simplifies some of the options control menus (albeit at the expense of some flexibility). But I like the extensive configuration control that Firefox provides. I’ll look forward to revisiting it in version 4. ;-)

    June 2nd, 2010 at 07:00

  64. Sadiq nasiry

    Well, I think it’s just new name but not a new difference because all
    the speed, plug ins and others are the same and same however the promotion is the tabs (upgrade from fx3.0) but for a dial-up connection no kind of difference!!!

    July 1st, 2010 at 00:07

  65. massschneider

    bumping up to over 100ms, then leveling off in the mid 90′s. I’m not surprised

    July 29th, 2010 at 08:15

  66. Jeffz

    FF latest – even with all add ons is still “jerky as h”.
    It’s JS animations are worse of all other browsers I test it on.
    Even IE7 is visibly better.

    FF should do something about complex JS animations.
    And fast.

    August 28th, 2010 at 14:20

    1. Jeffz

      I meant “all add ons off”

      August 28th, 2010 at 14:22

  67. max jones

    there is something about the way javascript is being handled that is different from earlier versions. trying to find out what is how i arrived here.

    right now firefox is nearly unusable. every few minutes i get a message about a “javascript that is unresponsive and do i want to continue.” whatever is going on brings my laptop to a halt. if i wait for 5 or 10 minutes it will free up enough cylcles to move on. mostly i just have to kill it and reboot. i have to wait until that “do you want to continue” message pops… often there is are a couple more javascripts that have become unresponsive that prevent me from stopping the first clicking stop in the dialog box…

    most of the problems are with gmail. at first i thought google might be pulling a microsoft to give chrome an advantage. but after watching it and figuring out which scripts were dying i concluded its more or less random. all are effected.

    running ubuntu 10.10.1. i’ve tried nightly builds but it doesn’t seem to be going away…

    October 29th, 2010 at 06:32

  68. psalmsninetyone

    I’m using firefox 3.6.12 and I’m getting this on the first run:

    Frame Delay: 18
    GC Delay: 14

    Then I get this on the second run:

    Frame Delay: 16
    GC Delay: 27

    The GC Delay figures rise as tabs increase (naturally) but the Frame Delay was pretty constant

    November 1st, 2010 at 22:49

  69. jhon

    i m using Firefox 3.6.15 with Greasefire ..its gr8

    March 17th, 2011 at 13:47

  70. BMorris

    JIT is one of the most important technology in browser history that was developed. Perhaps it will be nice for all browsers to adopt and implement JIT and comeup with a common standard for it and focus on optimizing it even more.

    March 23rd, 2011 at 03:58

  71. Chris

    Nice test app.

    My dial jerks every 2-3 turns and the GC delay is hovering around 80ms, this is with FF 3.6. I only have 12 addons, and I reckon the only big ones are adblock plus which I consider essential and tab mix plus which I also would struggle to do without. The rest are tiny ones like perspectives.

    March 30th, 2011 at 17:22

Comments are closed for this article.