5 ms·

New Firefox JavaScript engine is faster than Chrome's V8

19 points by prakash 18y ago

smoody 18y ago
It doesn't surprise me that IE javascript performance is worse. MSoft has incentive to keep it its Javascript engine throttled back. If it gets too fast, then javascript-based web apps will start to perform on-par with their office suite of apps, and then where will they be? ;-)
- cstejerean 18y ago
  I hope MS continues to think that way, it will only make them irrelevant sooner.
- run4yourlives 18y ago
  I don't think its so malicious. It's simply the case that MS has to support its own JS standard, in addition to the "standard".
  - snprbob86 18y ago
    This is exactly correct. Backwards compatability is a bitch. Additionally, you need to account for Microsoft scale approaches. There are two Javascript engines (that I know of) at Microsoft: IE's implementation and Managed JScript [1] which is built on the DLR [2]. The DLR is a set of extensions to the in-development .NET CLR 4.0 to support Managed JScript, IronPython, and IronRuby. The DLR is the place for all these fancy pants modern optimizations that Google, Mozilla, and Apple are implementing. In fact, the DLR already has many of them. I believe that Silverlight 2.0 (now released) has some version of the DLR in it and .NET 4.0 is coming sooner or later. Who knows if or when IE will ever use Managed JScript or the DLR. Remember: Microsoft is full of plenty of smart, non-evil engineers. You can try to call it ignorance, but really it is bloat, process, and scope. It's almost never malice ;-) [1] http://blogs.msdn.com/jscript/archive/2007/05/04/managed-jscript-announced.aspx http://blogs.msdn.com/jscript/archive/2007/05/04/managed-jsc... [2] http://en.wikipedia.org/wiki/Dynamic_Language_Runtime http://en.wikipedia.org/wiki/Dynamic_Language_Runtime
- briansmith 18y ago
  Microsoft already has a much faster Javascript engine in Silverlight, but they would need to make big changes in IE to integrate their next-generation Javascript implementation into it. Besides, the IE team's approach to performance is different than Mozilla's and Apple's approach. Instead of just improving raw performance, they look at entire use cases and try to optimize them for usability and performance. To the IE team, a 50% increase in some artificial benchmark means nothing, but a 50% decrease in the number of steps and/or the amount of wall time for the user to accomplish a task is very important. Here is what they had to say about their integrating their new Javascript implementation into IE: Chris Wilson [MS] (Expert): Q: Why not adapt the the Silverlight implementation of (managed) Javascript and fit it in IE.next? It's fast as hell. A: We've been looking at Javascript engines closely. The transitions back and forth between managed code (JScript.Net) and unmanaged code (IE's DOM) would be expensive, though, so it's not as much of a slam dunk as it might seem. - http://www.microsoft.com/windowsxp/expertzone/chats/transcripts/08_1016_ez_ie8.mspx http://www.microsoft.com/windowsxp/expertzone/chats/transcri... By the way, once a month you can join one of those chats and ask the IE developers any question you want.
wesley 18y ago
This is a month and a half old article, snore.
- johns 18y ago
  Snide comment aside, two months right now is an eternity for how fast these engines are evolving.
pchristensen 18y ago
Two words: Competition is great :)
- deleted 18y ago
  [deleted]
- cbetz 18y ago
  I hate to point out that there are three words there. Or is this comment some kind of joke that went over my head?
  - pchristensen 18y ago
    It was a joke. That's what the ":)" was for.
- michaelneale 18y ago
  It is indeed - but at what point are they fast enough and attention should be put on to (presumably) non JS items like DOM manipulation ? (or are they related, I know nothing about browser design other then how to write for them or use them, a bit).
scott_s 18y ago
Using one number to represent 14 benchmarks is meaningless. Check out the original blog to see the breakdown by benchmark, which is more informative: http://weblogs.mozillazine.org/roadmap/archives/2008/09/tracemonkey_update.html http://weblogs.mozillazine.org/roadmap/archives/2008/09/trac...
zhyder 18y ago
IMO chrome is overall ahead as long as it's the only browser with a separate process per tab. (Its memory management is a nice bonus too.)
arthurk 18y ago
TraceMonkey was the fastest engine two months ago, now its SquirrelFish Extreme.
rgrieselhuber 18y ago
FF3 still runs at 700 MB of RAM on my system. I've switched to Camino for daily browsing and FF for development only. Until they fix this ridiculous memory usage, I'm not switching back.
riobard 18y ago
I would like Firefox to steal the one-process-per-tab feature of Chrome, desperately. Sometimes when I have too many tabs running in the background with just a single one stop responding, Firefox stalls for a couple of minutes ...
shadytrees 18y ago
> Eich also praises Chrome. He says that the V8 JavaScript engine is "very-well engineered" and he describes the multiprocess design as "righteous". He went on to describe JavaScript as "totally OK" and "mauve."

19 points by prakash 18y ago

It doesn't surprise me that IE javascript performance is worse. MSoft has incentive to keep it its Javascript engine throttled back. If it gets too fast, then javascript-based web apps will start to perform on-par with their office suite of apps, and then where will they be? ;-)

cstejerean 18y ago
I hope MS continues to think that way, it will only make them irrelevant sooner.
run4yourlives 18y ago
I don't think its so malicious. It's simply the case that MS has to support its own JS standard, in addition to the "standard".
- snprbob86 18y ago
  This is exactly correct. Backwards compatability is a bitch. Additionally, you need to account for Microsoft scale approaches. There are two Javascript engines (that I know of) at Microsoft: IE's implementation and Managed JScript [1] which is built on the DLR [2]. The DLR is a set of extensions to the in-development .NET CLR 4.0 to support Managed JScript, IronPython, and IronRuby. The DLR is the place for all these fancy pants modern optimizations that Google, Mozilla, and Apple are implementing. In fact, the DLR already has many of them. I believe that Silverlight 2.0 (now released) has some version of the DLR in it and .NET 4.0 is coming sooner or later. Who knows if or when IE will ever use Managed JScript or the DLR. Remember: Microsoft is full of plenty of smart, non-evil engineers. You can try to call it ignorance, but really it is bloat, process, and scope. It's almost never malice ;-) [1] http://blogs.msdn.com/jscript/archive/2007/05/04/managed-jscript-announced.aspx http://blogs.msdn.com/jscript/archive/2007/05/04/managed-jsc... [2] http://en.wikipedia.org/wiki/Dynamic_Language_Runtime http://en.wikipedia.org/wiki/Dynamic_Language_Runtime
briansmith 18y ago
Microsoft already has a much faster Javascript engine in Silverlight, but they would need to make big changes in IE to integrate their next-generation Javascript implementation into it. Besides, the IE team's approach to performance is different than Mozilla's and Apple's approach. Instead of just improving raw performance, they look at entire use cases and try to optimize them for usability and performance. To the IE team, a 50% increase in some artificial benchmark means nothing, but a 50% decrease in the number of steps and/or the amount of wall time for the user to accomplish a task is very important. Here is what they had to say about their integrating their new Javascript implementation into IE: Chris Wilson [MS] (Expert): Q: Why not adapt the the Silverlight implementation of (managed) Javascript and fit it in IE.next? It's fast as hell. A: We've been looking at Javascript engines closely. The transitions back and forth between managed code (JScript.Net) and unmanaged code (IE's DOM) would be expensive, though, so it's not as much of a slam dunk as it might seem. - http://www.microsoft.com/windowsxp/expertzone/chats/transcripts/08_1016_ez_ie8.mspx http://www.microsoft.com/windowsxp/expertzone/chats/transcri... By the way, once a month you can join one of those chats and ask the IE developers any question you want.

wesley 18y ago

This is a month and a half old article, snore.

johns 18y ago
Snide comment aside, two months right now is an eternity for how fast these engines are evolving.

pchristensen 18y ago

Two words: Competition is great :)

deleted 18y ago
[deleted]
cbetz 18y ago
I hate to point out that there are three words there. Or is this comment some kind of joke that went over my head?
- pchristensen 18y ago
  It was a joke. That's what the ":)" was for.
michaelneale 18y ago
It is indeed - but at what point are they fast enough and attention should be put on to (presumably) non JS items like DOM manipulation ? (or are they related, I know nothing about browser design other then how to write for them or use them, a bit).

scott_s 18y ago

Using one number to represent 14 benchmarks is meaningless. Check out the original blog to see the breakdown by benchmark, which is more informative: http://weblogs.mozillazine.org/roadmap/archives/2008/09/tracemonkey_update.html http://weblogs.mozillazine.org/roadmap/archives/2008/09/trac...

zhyder 18y ago

IMO chrome is overall ahead as long as it's the only browser with a separate process per tab. (Its memory management is a nice bonus too.)

arthurk 18y ago

TraceMonkey was the fastest engine two months ago, now its SquirrelFish Extreme.

rgrieselhuber 18y ago

FF3 still runs at 700 MB of RAM on my system. I've switched to Camino for daily browsing and FF for development only. Until they fix this ridiculous memory usage, I'm not switching back.

riobard 18y ago

I would like Firefox to steal the one-process-per-tab feature of Chrome, desperately. Sometimes when I have too many tabs running in the background with just a single one stop responding, Firefox stalls for a couple of minutes ...

shadytrees 18y ago

> Eich also praises Chrome. He says that the V8 JavaScript engine is "very-well engineered" and he describes the multiprocess design as "righteous". He went on to describe JavaScript as "totally OK" and "mauve."