One of our goals with Firefox 3.5 is to help upgrade the web. Over the lifecycle of this release we’ve invested heavily in developer features. One of the features that we’ve invested in is TraceMonkey – a tracing interpreter that turns commonly-run JavaScript code into machine code so that it can run at near-native speeds. We consider it to be both an end user feature because it makes existing web applications faster as well as a developer feature because of the new kinds of applications it enables.

We’re always challenged to try and come up with ways to describe what that means in a way that’s not a dry benchmark. How can we explain what it feels like?

We’ve made a video to help describe both what it means by the numbers, but also shows what it feels like. If you want to try the demo we suggest you try it in both Firefox 3 and Firefox 3.5. It’s something you can really feel.

Sadfaces. Your browser doesn’t support native video. Maybe you can try the .ogv version or the .mp4 version and hope for the best?

61 comments

Post a comment

  1. Mike Beltzner wrote on June 11th, 2009 at 9:16 pm:

    Vlad’s updated the demo (cleaned up some code) for people who want to check out a different version. Runs even faster on TraceMonkey enabled browsers:

    http://people.mozilla.com/~vladimir/mdemos/imgmanip/image.html

    Reply

  2. Artur Pokusin wrote on June 11th, 2009 at 9:25 pm:

    Wow. Just from the demo, it looks really powerful and convenient. I hope it makes it far, and that IE, Safari, and Chrome are developed to support this.

    Reply

  3. Matt Wilkinson wrote on June 11th, 2009 at 9:26 pm:

    Blizzard, thanks for the demo! I love telling people about how much faster FF 3.5 is when compared to FF 3.

    By the way, I also closely follow your open video crusade on your blog. What’s an easy way for me to record an open video like the one here?

    -Matt

    Reply

  4. Christopher Blizzard wrote on June 11th, 2009 at 9:38 pm:

    @Matt That video was originally recorded in screenflow, edited heavily in a combination of Screenflow and Final Cut Pro and was exported into both Ogg Theora and mpeg4 formats. So pretty standard tools just with a slightly different export method.

    Reply

  5. Pingback from 颠覆网络35天 ─ 亲身“触摸” TraceMonkey < MJiA on June 11th, 2009 at 10:07 pm:

    [...] 原文地址：what does tracemonkey feel like? [...]

    Reply

  6. Pingback from Fightskillz.com » Blog Archive » Firefox: Tracemonkey on June 11th, 2009 at 10:40 pm:

    [...] Safari 4 and was blown away by how fast it was in the Javascript department. Well head over to http://hacks.mozilla.org/2009/06/tracemonkey-demo/ and test the image rendering demo in Safari 4 compared to the current Firefox(3) and the video demo [...]

    Reply

  7. Drazick wrote on June 11th, 2009 at 11:40 pm:

    How come Chrome perform so badly on this test yet in any other day to day task it out performs Firefox 3.5 Pre easily?

    I think trace monkey is great, yet it feels it’s still behind V8 and Nitro.

    Thanks.

    Reply

  8. Wolfgang Rosenauer wrote on June 12th, 2009 at 12:19 am:

    So from the numbers I get tracemonkey still doesn’t fully support x86-64 on Linux :-( That’s very sad.

    Reply

  9. Erunno wrote on June 12th, 2009 at 12:24 am:

    Interesting test, I tried it with Safari 4 and to my immense surprise is was slower than with Firefox 3. Safari needed in average about 900 ms to draw a frame while Firefox 3 around 700. I haven’t had the chance to try it with 3.5 yet as I don’t like to use beta software.

    Is there any explanation for this number? In most synthetic tests the Nitro engine is actually a good deal faster then TraceMonkey. This test could be actually quite valuable for marketing as it shows that TraceMonkey is faster in “real-world” scenarios.

    Reply

  10. PA wrote on June 12th, 2009 at 12:49 am:

    I feel no big difference between 3.0 and 3.5. Maybe I am missing something ? Is Linux version concerned ?

    Reply

  11. Sandy wrote on June 12th, 2009 at 3:45 pm:

    @Drazick: You cannot measure browser performance with one test. Firefox, Chrome, Safari, et al are each faster at different things. Get used to the fact that the question of “fastest browser” is not black and white.

    Reply

  12. Ka-Hing Cheung wrote on June 12th, 2009 at 5:32 pm:

    re: Wolfgang Rosenauer

    Looks like trunk has AMD64 support (from looking at the code)

    Reply

  13. will_in_wi wrote on June 12th, 2009 at 5:51 pm:

    I get a draw time of 1763ms while adjusting contrast on x86_64 ubuntu linux using the latest 3.5 nightlies. These nightlies are compiled by and distributed by the ubuntu-mozilla-daily ppa team, so they are true 64 bit. Does the JIT compiler not support 64bit? Or Linux? Or are the compile flags off?

    Reply

  14. Christopher Blizzard wrote on June 12th, 2009 at 6:43 pm:

    We don’t have 64 bit support for Linux in 3.5. Sounds like it’s coming at some point, though.

    Reply

  15. Mecki wrote on June 13th, 2009 at 5:35 pm:

    Nitro is not just faster as synthetic tests. E.g. I use stackoverflow.com a lot. When you type a question or answer on this page (using some wiki like syntax) JS code translates that into a preview in real time. Working on a very long answer/question in Fx 3.0.x becomes really cumbersome on my slow system. Doing the same in 3.5beta99 with TraceMonkey enabled for sure is a lot faster, but still somewhat sluggish. Doing the same thing in Safari 4 is lighting fast. This is a real live scenario, no synthetic test of any kind, where Nitro clearly beats TraceMonkey and I don’t have to benchmark that, I can see it and I can feel it.

    Reply

  16. Erunno wrote on June 14th, 2009 at 1:05 am:

    @Mecki

    True, there are also some demanding JavaScript demoes on http://www.chromeexperiments.com/ which run smooth with both Nitro and V8 but not with TraceMonkey.

    Reply

  17. Mecki wrote on June 14th, 2009 at 5:07 am:

    I think TraceMonkey was a necessary step and certainly a step into the right direction – however there is still a lot of potential. Other browser vendors show that JS can run even a lot faster than TraceMonkey can currently run it. For webpages TraceMonkey might be more than fast enough in most cases, however unless I’m wrong the goal of Mozilla is to replace more and more native code in Firefox with JS (as it’s cross platform and makes porting much easier). In the future only certain rendering, network, and file access function will be native, but pretty much all other browser logic won’t. This is a great idea for the future of Firefox, but TraceMonkey is still too slow at the moment to achieve this goal.

    Reply

  18. Ryan Hayle wrote on June 17th, 2009 at 9:43 am:

    How can you seriously release any product which does not support x86_64 in this day and age? This architecture has been around for 10 years now, and they haven’t sold 32-bit CPUs in years, other than on netbooks. The vast majority of users should be using 64-bit operating systems. It is so frustrating to constantly have modern (not even state of the art!) platforms ignored in favour of outdated, 10+ year-old platforms. I hope this changes, and Mozilla starts to take x86_64 seriously (including releasing x86_64 binaries). I understand that this is a beta and “you’re working on it” and I am not just being impatient here. My point is that x86_64 should be your first priority, 32-bit should be on the backburner, especially as the number of 32-bit users decreases every day.

    Reply

  19. Christopher Blizzard wrote on June 17th, 2009 at 11:00 am:

    @Ryan – I understand that you are upset. But the distributions do build x86_64 binaries and distribute them. We just don’t support it in tracemonkey quite yet.

    Also the world does not switch overnight.

    Reply

  20. Matt Wilkinson wrote on June 17th, 2009 at 11:50 am:

    @Ryan To expand on Blizzard’s comments: it’s important to understand that the largest platform for Firefox is (unfortunately) Windows. Windows and OS X are what most end users have on their computers and Firefox with Tracemonkey works on those platforms. Mozilla is developing a 64-bit version of Firefox.next for OS X, but Firefox doesn’t have to be 64-bit for it to function on a 64-bit OS.

    For example, I use 64-bit Windows 7 and OS X Leopard and Firefox works fine with TraceMonkey.

    I can tell you’re a big fan of 64-bit Linux, but that is a niche that not a lot of people are using. You’re talking about a wonderfully powerful OS (Linux), but not a lot of end users are on that, not to mention 64-bit Linux. So c’mon you’re going to have to understand Mozilla’s priorities here. It just doesn’t make sense to put all of their resources on x86_64 Linux. No sense at all. They have bigger fish to fry right now, and they’re doing a superb job as far as I’m concerned.

    Also, 64-bit JUST became mainstream like last year on Windows. Snow Leopard will be mostly 64-bit, but it will still have elements of the OS that are running at 32-bit. So the argument that the entire world is running 64-bit is false.

    -Matt

    Reply

  21. Ka-Hing Cheung wrote on June 17th, 2009 at 3:03 pm:

    @Matt – Tracemonkey on 32bit firefox works fine on 64bit Linux too, but that’s not what Ryan was complaining about. The issue is that Tracemonkey on 64bit firefox just doesn’t work yet (not in 3.5 anyway), and that’s the same on any platform.

    I don’t think it’s as a big deal as Ryan made it sound though.

    Reply

  22. Matt Wilkinson wrote on June 17th, 2009 at 3:10 pm:

    @Ka-Hing Cheung Right. Either way, it’s not as big of a deal as Ryan is making it out to be. Again, simply because the userbase of 64-bit Firefox and/or 64-bit Linux is so small that it can’t be a priority.

    That’s what I think anyway.

    Reply

  23. Dannii wrote on June 19th, 2009 at 8:37 pm:

    Maybe the userbase is so small because its neglected?

    Reply

  24. Ryan Hayle wrote on June 29th, 2009 at 12:33 pm:

    I realize sounded more than a bit raving in that last post, but I still think the sentiments were justified. I know the world does not switch overnight, but it has been 10 years, which as we all know, is an eternity in “computer years”.

    My concern is that people are going to excitedly download and run the shiny, new Firefox 3.5–it’s primary claim being a huge increase in speed and performance–on their fancy, new machines and be very disappointed. I’m only getting around 1200 on the Peacekeeper benchmark on a 2.4GHz Core2 Duo T8300, I assume primarily because of having no Tracemonkey support. Chromium nightly is giving me 2900+.

    What bothers me is not having a slower browser myself, but rather feeling like the developers are focusing on a very outdated platform. I realize you want to focus on Windows/Mac–that is a whole different argument and I’m not suggesting anyone devote all their resources to Linux. However, within the Linux development effort itself, I would expect the current focus to be on 64-bit. Do many people actually use 32-bit Linux on a 64-bit CPU? It’s entirely likely I am simply unaware of this, I just can’t fathom why someone would do this. I don’t know anything about the proprietary operating system twins, or why they are so backward and only getting 64-bit support now, but that is beside the point.

    I do not want to run a 32-bit Firefox because it would have to exist outside of my distribution and have completely separate 32-bit plugins installed.

    I’m not just trying to be critical, the whole development community has done an amazing job and I am not disparaging any of their work. I do question whether enough consideration is given to this issue, however. I’m not impatient at all and I know that developing quality software takes time. I just don’t believe it’s right for Mozilla to release a product that functions only partially on some platforms, simply because they are considered “niche”. This puts it in the same camp as Google, Skype and other proprietary software vendors that do not release Windows and Linux software versions concurrently. As the poster-child for open source software, I would really hate to see that happen!

    I do take full responsibility for not working on getting TraceMonkey to work on 64-bit platforms myself, and yet being one to complain about it. I am trying to contribute something more constructive than mere ranting!

    Reply

  25. Dirk wrote on June 30th, 2009 at 2:53 pm:

    To the question from the title: “what does tracemonkey feel like?”

    Well, it feels like … um … nothing, because it’s not compatible with current systems, only with outdated 32 bit machines.

    FAIL.

    Reply

  26. greg wrote on July 1st, 2009 at 6:06 am:

    So… with TraceMonkey apparently working fine on 64-bit systems with Firefox trunk, is this going to get merged back into Firefox 3.5? I seriously hope so.

    Reply

  27. Raymond Right wrote on July 1st, 2009 at 1:17 pm:

    Like most other developers, the folks at Mozilla recognize that closed source technologies and platforms like Windows and OS X are the real way to go. Open source is fine for useless things like web browsers and web servers, but only closed source operating systems give you that minty fresh feeling.

    Reply

  28. Gfterry wrote on July 1st, 2009 at 3:44 pm:

    Mozilla’s Firefox has taken a lot of market share from IE because Microsoft wouldn’t listen to users who requested that IE keep up with technical advancement.

    Now Mozilla is following in Microsoft’s footsteps.

    When you can get 4 GB of RAM for $40, how long do you think 32-bit is going to remain king of the desktop?

    The totally dismissive attitude towards 64-bit users who want to stay loyal to Mozilla and Firefox is a disgrace. If I’ve got to hack a 32-bit browser to work on a 64-bit system, I’ll use Google’s Chrome, which Mozilla is giving plenty of time to catch up with Firefox.

    Reply

  29. Mecki wrote on July 1st, 2009 at 4:39 pm:

    @Ryan Hayle: I don’t get your point. Sorry. According to Ka-Hing Cheung a 32 Bit Firefox runs just fine on 64 bit Linux. So what exactly is your problem then? You say “buhhuuuu, 64 bit Linux, buuuhuuu 64 bit CPU”, yes, all fine. Have a 64 bit CPU, run a 64 bit Linux and give me only one good reason why you cannot use a 32 bit Firefox on that.To quote your post:

    “I do not want to run a 32-bit Firefox because it would have to exist outside of my distribution and have completely separate 32-bit plugins installed.”

    Well, that is then a problem of your personal preference, I’d say. I, as a Mac user, are used to mix 32 and 64 bit all the way. In 10.4 only background processes (like server processes, database processes, and so on) could be 64 bit, not UI processes and the kernel itself was also 32 bit only. In 10.5 background and UI processes could be 64 bit, only the kernel itself was limited to 32 bit. With the upcoming 10.6 all processes (including the kernel) can be 64 bit. That is *can be*, not *will be* or *have to be*. I’m running 32 bit and 64 bit processes side by side each day, sometimes on a 64 bit kernel and sometimes on a 32 bit kernel.

    If TraceMonkey is so important to you, use a 32 bit Firefox and enjoy fast JS support. If 64 bit is so ultra important to you, then use the 64 bit Firefox and please stop whining. Since unlike your posts imply, 64 bit Linux users can enjoy full TraceMonkey speed on their 64 bit CPUs. All they need to do is using a 32 bit Firefox; something that is no problem to thousands of them. The whole thing is rather an issue that Mozilla development is not compatible to limitations you impose upon yourself.

    I use a 32 bit Firefox right now on a 64 Bit OS-X kernel running on a 64 bit CPU, it has TraceMokey and it kicks ass!

    Reply

  30. Matt Wilkinson wrote on July 1st, 2009 at 4:42 pm:

    @Mecki Exactly.

    Reply

  31. Gfterry wrote on July 1st, 2009 at 5:11 pm:

    Mozilla’s Firefox has taken a lot of market share from IE because Microsoft wouldn’t listen to users who requested that IE keep up with technical advancement.

    Now Mozilla is following in Microsoft’s footsteps.

    When you can get 4 GB of RAM for $40, how long do you think 32-bit is going to remain king of the desktop?

    Does this sound familiar to the 32-bit bigots: “Nobody will ever need more than 640k RAM!”

    The totally dismissive attitude towards 64-bit users who want to stay loyal to Mozilla and Firefox is a disgrace. If I’ve got to hack a 32-bit browser to work on a 64-bit system, I’ll use Google’s Chrome, which Mozilla is giving plenty of time to catch up with Firefox.

    Reply

  32. Someone wrote on July 1st, 2009 at 7:41 pm:

    @Mecki and @Matt Wilkinson

    Firefox developers are PROFESSIONAL and develop a VERY popular and widely used package. They should NOT release 32-bit and skip a 64-bit release. They should be simultaneous. If they cannot handle this, then I question their future dominance.

    This is not the first thing they’ve let slip in the past months!

    Get it together Firefox, or we’ll throw our weight behind something that’s faster and gets rid of the bloat!

    S.

    Reply

  33. David wrote on July 1st, 2009 at 9:54 pm:

    I think Ryan still has a point. If one of the major features of the new browser is unavailable in 64bit, then that’s a fairly big oversight. The major benefit of 64bit is speed, yet that is exactly what is crippled in this 64bit version. I just hope the fix gets included in the next bug fix release and we don’t have to wait for FF4 to see 64bit FF running as it should. (where do you get the 64bit version anyway? I can’t find any reference to it on Mozilla’s website)

    Aside from that, what I’m really hoping is that Firefox’s performance on Linux has been improved so that it’s at least as fast as FF3′s performance on Windows. Guess I’ll just have to try it out to find out…

    Reply

  34. Silf wrote on July 2nd, 2009 at 1:32 am:

    @Mecki Since unlike your posts imply, 64 bit Linux users can enjoy full TraceMonkey speed on their 64 bit CPUs. All they need to do is using a 32 bit Firefox; something that is no problem to thousands of them.

    I have to disagree with you. If you have 64 bit linux (a lot do, because it is faster and it is already everything ported to 64bit) you already have all plugins that are 64bit. So if you want to downgrade to 32 bits, you have to replace all plugins like totem, flash, … that are otherwise available in default 64 bit installation. nspluginwrapper can run 32 bit plugins inside 64 bit browser, but not the other way around. Not trivial change for ordinal user (http://ubuntuforums.org/showthread.php?p=1174435). I think that somebody should add that this manual is no longer obsolete for FF 3.5 :)

    Even on mac you can have problems. Apple still after 3 year since java6 is released and there is no 32bit version only 64bit (we need java6 inside firefox (due to added NSS support).

    I agree with you, that it is not critical, but I am sure you can see, why linux people would appreciate 64 bit support :)

    I really hope that linux distributions use 64 bit tracemonkey support from trunk.

    @Mecki The whole thing is rather an issue that Mozilla development is not compatible to limitations you impose upon yourself.
    Are you sure that we are limiting ourselves? I bet 64 bit tracemonkey would kick 32bit tracemonkey sorry ass ;) And if you are already using 64 bit mac, wouldn’t you then prefer even faster 64 bit firefox.

    Reply

  35. Silf wrote on July 2nd, 2009 at 1:49 am:

    @Mecki Since unlike your posts imply, 64 bit Linux users can enjoy full TraceMonkey speed on their 64 bit CPUs. All they need to do is using a 32 bit Firefox; something that is no problem to thousands of them.

    I have to disagree with you. If you have 64 bit linux (a lot do, because it is faster and it is already everything ported to 64bit) you already have all plugins that are 64bit. So if you want to downgrade to 32 bits, you have to replace all plugins like totem, flash, … that are otherwise available in default 64 bit installation. nspluginwrapper can run 32 bit plugins inside 64 bit browser, but not the other way around. Not trivial change for ordinal user (http://ubuntuforums.org/showthread.php?p=1174435). I think that somebody should add, that this manual is no longer obsolete for FF 3.5 :)

    Even on mac you can have problems. Apple still after 3 years since java6 is released, there is no 32bit version only 64bit (we need java6 inside firefox due to added NSS support).

    I agree with you, that it is not critical, but I am sure you can see, why linux people would appreciate 64 bit support :)

    I really hope that linux distributions use 64 bit tracemonkey support from trunk.

    @Mecki The whole thing is rather an issue that Mozilla development is not compatible to limitations you impose upon yourself.
    Are you sure that we are limiting ourselves? I bet 64 bit tracemonkey would kick 32bit tracemonkey’s sorry ass ;) And if you are already using 64 bit mac, wouldn’t you then prefer even faster 64 bit firefox.

    It seems my previous post was lost.

    Reply

  36. Robert wrote on July 2nd, 2009 at 10:27 am:

    “32 Bit Firefox runs just fine on 64 bit Linux.”. Sorry, but that’s not true. If you don’t want to carry 32bit versions of your plugins, you are stuck:
    LoadPlugin: failed to initialize shared library /usr/lib/jvm/java-6-openjdk/jre/lib/amd64/IcedTeaPlugin.so [/usr/lib/jvm/java-6-openjdk/jre/lib/amd64/IcedTeaPlugin.so: niewłaściwa klasa ELF: ELFCLASS64]
    LoadPlugin: failed to initialize shared library /usr/lib/jvm/java-6-openjdk/jre/lib/amd64/IcedTeaPlugin.so [/usr/lib/jvm/java-6-openjdk/jre/lib/amd64/IcedTeaPlugin.so: niewłaściwa klasa ELF: ELFCLASS64]
    LoadPlugin: failed to initialize shared library /usr/lib/mozilla/plugins/libflashplayer.so [/usr/lib/mozilla/plugins/libflashplayer.so: niewłaściwa klasa ELF: ELFCLASS64]
    LoadPlugin: failed to initialize shared library /usr/lib/mozilla/plugins/kaffeineplugin.so [/usr/lib/mozilla/plugins/kaffeineplugin.so: niewłaściwa klasa ELF: ELFCLASS64]
    (and others)

    I have abandoned all the practices including chrooting when Sun/OpenJDK released both 64 bit version of Java plugin. That was the last thing keeping me with 32bit. I’m not so eager to use 3.5 version of Firefox, so I can wait.

    Reply

  37. Mecki wrote on July 2nd, 2009 at 3:16 pm:

    @Silf and @Robert: So you have 64 Bit plugins and this prevents you from also having 32 Bit plugins? Sorry, but the more I read here, the more I get the problem that the wohle problem is that Linux is a poorly designed OS in this aspect. Sorry, I didn’t want to make an OS flamewar out of this…. however pretty much every Mac OS X user in the world uses 32 Bit and/or 64 Bit applications each day without even *knowing* which application is 32 Bit and 64 Bit as they integerate absolutely seemlessly in OS X! Why can Apple make a system, that bases on BSD after all, where 32 Bit and 64 Bit coexist side by side transparently to the user and on Linux you must do all kind of hacks to get the same result? Why can Apple ship every system library, every plugin, every part of the system as both, a 32 Bit and a 64 Bit version and Linux cannot? Actually I don’t even think Linux cannot, I think Linux could and it’s just your distribution that is making these problems. As Ryan said, he doesn’t want to leave the path of his distribution. Why can’t your Linux distribution offer a 32 Bit Firefox *AND* a 64 Bit Firefox and all plugins also in both versions, so you are free to use either one on your 64 Bit system and either one will work with all plugins and without you even wasting a single second of your day thinking about whether this is a 32 Bit or a 64 Bit process?

    @David: The major benefit is speed? Oh come on. I though users here are technically advanced enough to not fall for this marketing babbling. Where is 64 Bit faster? 64 Bit is only faster if you do heavy 64 Bit integer math, what almost no application does (I estimate 90% of all integer math in Fx, even in 64 Bit Fx is 32 Bit) and if you use some very obscure algorithm that can really profit of a few more spare CPU registers. That most algorithms have no use for them is clearly shown by the fact that x86 code with only (about) 6 available registers has overtaken the PPC architecture with 16 Registers in speed at some point for the same number of cores and same GHz clock frequency. Who really thinks any piece of C/C++ code runs faster just because you compile it with a 64 Bit GCC has most likely never developed anything much bigger than Hello World in C. Actually in 64 Bit all memory pointers are twice the size, causing the first level caches of a CPU for code and data to fill up much faster, causing more cache misses and more slow memory accesses than the same piece of code compiled to 32 Bit. The only two valid reasons for “having” to use 64 Bit are either an application that does over 50% 64 Bit Integer math or because you need more than a 4 GB virtual address space (e.g. a SQL Database or an Apache Server would fall into that category). Neither of both applies to a web browser in general and not to Fx in particular.

    Reply

  38. Silf wrote on July 2nd, 2009 at 6:07 pm:

    @Mecki So you have 64 Bit plugins and this prevents you from also having 32 Bit plugins? Sorry, but the more I read here, the more I get the problem that the wohle problem is that Linux is a poorly designed OS in this aspect.
    You can have it, but if you have checked my link you can see that it is not quite trivial. Universal binaries are great in that aspect. Linux mostly need only one version of binaries, since basically everything is already ported to 64 bits (yes even flash and java). Apple is only on the half way of this. In two months Snow Leopard will have more and more things ported to 64 bit (like Safari).

    @Mecki Why can Apple ship every system library, every plugin, every part of the system as both, a 32 Bit and a 64 Bit version and Linux cannot?
    So you are saying Apple can port everything to 64 bit ports and mozilla can not? But still even Apple can’t ;) Java6 is still available only as 64 bit version. Can you point me to how can I run Firefox or Safari using Java6 on MacOSX (not just trolling, I would really like to know).

    @David: The major benefit is speed? Oh come on. I though users here are technically advanced enough to not fall for this marketing babbling.
    According to Apple Safari 4 in Snow Leopard will be 64 bit and faster for about 50%. So they say.
    And as you have states. There are algorithms that do actually benefit from 64bit. And since javascript is kind of a programming language and browser itself quite complex, there are algorithms inside that can benefit too.
    For example working with images is faster in 64bits. And since browsers tend to do that quite a lot you can see at least one benefit here.
    http://www.favbrowser.com/firefox-32-bit-x86-vs-firefox-64-bit-x64/

    Reply

  39. Pingback from Firefox 3.5 review - icewind's Blog ³ on July 3rd, 2009 at 12:36 pm:

    [...] weigert sich ja, Firefox 3.5 für 64-Bit-Systeme herauszubringen. Die derzeit einzige mir bekannte [...]

    Reply

  40. Pingback from Sean Neakums (sneakums) 's status on Sunday, 05-Jul-09 06:05:01 UTC - Identi.ca on July 4th, 2009 at 11:05 pm:

    [...] @gabe in the comments on http://hacks.mozilla.org/2009/06/tracemonkey-demo/ [...]

    Reply

  41. Cliff Wells wrote on July 6th, 2009 at 7:59 pm:

    The issue here isn’t just about 32-bit Linux vs 64-bit Linux. It’s about a little loyalty for the platform that helped launch Mozilla to where it is today (how many Linux users spent hours convincing their Windows- and OSX-using friends to switch to Firefox?). Firefox is the primary browser on Linux, and the secondary browser on Windows and OSX. There’s a definite feeling that perhaps Linux users’ loyalty is being taken for granted and I venture that this is where some of the complaining is really rooted. It’s not so much about feature X as it is that there is a definite sense (and one that appears to getting some confirmation here) that Linux has been getting much less attention than the commercial platforms from the FF team.

    I personally don’t have any issues installing 32-bit software on my 64-bit Linux distro. Unfortunately, if I switched to 32-bit FF, I’d also have to switch back to the crappy 32-bit Flash player and suffer through endless FF crashes. Not a winning choice.

    I expect that the loyalty of Firefox’s Linux base will be truly tested when Chrome for Linux is final. I also expect that much of the proselytizing previously done by Linux users on FF’s behalf will shift to Chrome. Therefore I predict that losing Linux users will ultimately mean losing Windows and Mac users as well.

    Linux users are nothing if not zealots ;-)

    Reply

  42. Mecki wrote on July 7th, 2009 at 2:08 am:

    @Cliff: Firefox is the primary browser of Linux? Says who? I think pretty much every KDE user disagrees, after all KDE comes with an own browser (Konqueror) and its anything but bad (the underlying library is the same as Apple uses for Safari. KHTML is the base of WebKit). And the fact that the 32 Bit Flash plugin seems to be crappy is hardly the fault of Mozilla or Linux; the question is rather why can Adobe write a decent 64 Bit plugin but fails so badly at their 32 Bit version. Further Fx is how old now? About 5 years? So you could happily use this browser for 5 years without Tracemonkey and now, just because you’ll have to wait a couple of extra months to get Tracemonkey for 64 Bit Linux, your whole world breaks apart? You cannot be serious.

    I’m a developer myself and as a developer I would always first implement something 32 Bit, then port it to 64 Bit. Never ever the other way round. Not in 20 years. Not unless there will be *only* a 64 Bit version of course. Why? Easy. Porting 32 Bit code to 64 Bit code is extremely less work than porting 64 Bit code to 32 Bit code. That’s very logical. Porting from more limited to less limited is always easy than porting from less limited to more limited.

    So what do you people really want? Yes, TraceMonkey for 64 Bit Linux. That was not my question :-P I mean what do you really want of Mozilla in their development. Here are your choices:

    1) Mozilla releases TraceMonkey only if they have a 32 Bit and a 64 Bit version of it. -> Result: Either 3.5 had no Tracemonkey enabled by default at all (and it would ship with 3.6 or 4.0 in who knows how many months/years) or the 3.5 release had been delayed another couple of months, leaving Fx for all users with slow JS and maybe causing Fx to dramatically lose customer base, becoming a big loser of the browser war. Is that what you want?

    2) Mozilla first makes the 64 Bit version, releases and adds the 32 Bit version later on. IOW more than 90% (maybe more than 95%) will have no TraceMonkey support (most Windows users are still XP and not XP64, Vista is still rather rare where I live and Vista64 is almost exotic; Mac version is only 32 Bit anyway and Linux 32 Bit base still outnumbers 64 Bit base by a lot). -> Result: See above. As most users have slow JS and must wait for TraceMonkey, for all these users it is the same as if TraceMonkey is not part of the release at all. So Mozilla must fear to lose the browser war, lose customer base and could as well have released 3.5 without TM support for anyone. Again, is that what you want?

    By releasing TM as soon as possible and thus releasing 3.5 as soon as possible Mozilla made a lot of users happy (all 32 Bit users and that is far more than 50%! Far more…), Mozilla is fighting again in the upper class of the browser war (before the release the world was laughing at Fx’s slow JS support). This is a much better tactic than the two above and that’s why Mozilla made exactly that.

    And all you 64 Bit Linux guys have to do is wait a couple of months more to get this feature of the browser you love. If I see how hard you argue against Mozilla here, I honestly think you should chose a different browser, at best one that is 64 Bit only, and be happy for life. As trying to force Mozilla down a road that is absolutely destructive for them and for the Fx market share, just that *you* personally can be happy, is so extremely selfish, that I think the Mozilla community and the Fx user base can lead a prosper life without you.

    Reply

  43. David wrote on July 7th, 2009 at 5:00 am:

    @Mecki:
    I think you missed the point. The problem was FF3.5 64bit being released without Tracemonkey. If I’m wrong, then by all means, correct me, and everyone else who’s annoyed with 64bit FF not having Tracemonkey. If I’m wrong, then yay, if not, then quit trolling.

    As for Konquerer vs Firefox market share, please, by all means show me some stats that support your argument. Going by Net Application’s stats, Konquerer doesn’t even show up. That gives Konquerer a market share of <= 1% on Linux (unless my math sucks, which it very well might). So either there aren’t many KDE users, or most KDE users aren’t using Konquerer. Probably more the latter.

    Reply

  44. Mecki wrote on July 7th, 2009 at 8:21 am:

    @David: No, you missed my point. I totally understand that there is no TM in 64 Bit Fx. My question was, what should Mozilla have done instead. Not releasing TM at all, because 64 Bit TM is not ready? Not realy 3.5 at all, because 64 Bit TM is not ready? Why can’t you answer that question? You are now the boss of Mozilla. 32 Bit TM is ready, 64 Bit TM is not and the whole world waits urgently for TM and makes fun about Fx’s slow JS engine. So, as Mozilla boss, what had you decided? This is a simple question and not just me, I guess pretty much everyone following this thread is exited to hear your reply.

    Reply

  45. David wrote on July 7th, 2009 at 3:48 pm:

    @Mecki: Err, how about wait with releasing 64bit FF3.5 until Tracemonkey is ready for 64 bit? That sounds like a simple solution to me.

    Reply

  46. Mecki wrote on July 8th, 2009 at 2:40 am:

    @David: Okay. Then all Fx 64 users would come here and complain that they have no Fx 3.5 and we had the same situation like now. Except that they don’t just complain about not having TM, but also complain about not having all the other features (the new CSS stuff, the HTML5 support, the video and audio tags, pretty much everything this whole blog is talking about is not there for them). So I think this decision had caused much more protests and much more upset users than the way it is now. The way it is now, they *do* have all these features, just no TM, but therefor everything else.

    Reply

    1. Cliff Wells wrote on March 22nd, 2011 at 3:44 pm:

      Wow, it’s like you can’t read.

      In any case, in the two years since this thread was written, Firefox has lost 4% market share while Chrome has gained 14%. Now *you’re* the boss of Mozilla. Can you explain what you did wrong?

      Reply

  47. Pingback from Javascript speeds in Firefox 3.5, Chome 2.0, and Internet Explorer 8 « Reformed Musings on July 11th, 2009 at 9:14 am:

    [...] a great post called what does tracemonkey feel like? by Mozilla’s Director of Evangelism. In his post, he points to an online mini-benchmark with [...]

    Reply

  48. Pingback from 谋智社区 » Blog Archives » 颠覆网络35天 ─ 亲身“触摸” TraceMonkey on July 12th, 2009 at 10:26 pm:

    [...] 原文地址：what does tracemonkey feel like? [...]

    Reply

  49. adriano wrote on July 15th, 2009 at 2:06 am:

    is there any development news on tracemonkey @64bit?

    Reply

  50. Christopher Blizzard wrote on July 15th, 2009 at 6:42 am:

    64 bit support is coming. We were talking about that at the development meeting a couple of days ago.

    Reply

1 2

Add your comment

  5.