Firefox Gets Massive JavaScript Performance Boost

monkeymonkey writes "Mozilla has integrated tracing optimization into SpiderMonkey, the JavaScript interpreter in Firefox. This improvement has boosted JavaScript performance by a factor of 20 to 40 in certain contexts. Ars Technica interviewed Mozilla CTO Brendan Eich (the original creator of JavaScript) and Mozilla's vice president of engineering, Mike Shaver. They say that tracing optimization will 'take JavaScript performance into the next tier' and 'get people thinking about JavaScript as a more general-purpose language.' The eventual goal is to make JavaScript run as fast as C code. Ars reports: 'Mozilla is leveraging an impressive new optimization technique to bring a big performance boost to the Firefox JavaScript engine. ...They aim to improve execution speed so that it is comparable to that of native code. This will redefine the boundaries of client-side performance and enable the development of a whole new generation of more computationally-intensive web applications.' Mozilla has also published a video that demonstrates the performance difference." An anonymous reader contributes links the blogs of Eich and Shaver, where they have some further benchmarks.

Comments

As fast as C code???

[ACDChook]

Correct me if I'm wrong, but generally speaking, I was always under the impression that, as an interpreted language, javascript will never be able to run 100% as fast as natively compiled C code.

Re:As fast as C code???

[Anonymous Coward]

Correct me if I'm wrong, but generally speaking, I was always under the impression that, as an interpreted language, javascript will never be able to run 100% as fast as natively compiled C code.

Well, it has a JIT compiler, so that would transform it into bytecode essentially. It's the reason why C# is as fast as C code, because it too has a JIT. Google JIT :)

Re:As fast as C code???

[Bjarke Roune]

The optimization in the story is to compile parts of code written in Javascript. So when using this optimization, the Javascript is only partly interpreted, and if the compiled part is the part that takes up most of the runtime, then the Javascript could conceivably be something like the speed of natively compiled C.

Re:As fast as C code???

[Anonymous Coward]

Does that also mean it's NOT as fast as native C/C++ code because C# is blatantly not and thus is part of the marketing guff that you were gulliable to believe?
Next you'll be telling me Java hasn't got obscene memory requirements in comparison to native C/C++...

Re:As fast as C code???

[Rockoon]

The amount of ignorance in this community is quite disturbing. I suspect that part of the cause is the unchecked pro-c religion, which always begins "C as faster than ...."

Clue phone guys. Ring. Ring.

C is a high level language and like all high level languages it can either be compiled, interpreted, or even translated. JavaScript is no different than C and can also also be compiled, interpreted, or even translated. There is nothing special about the C language that makes it inherently faster than other languages. C itself is a derivation of the language BCPL, whos shortcomming was a lack of datatypes. The design goal of these language syntaxes was parsing with minimal overhead because RAM was in short supply in those days. C was not designed to be "faster" than anything.

C is commonly mistaken to be superior because the most popular C compilers are commonly more advanced than the compilers of other languages due to simple supply and demand metrics. C is more popular, so its compilers have traditionally gotten more development effort. C itself isnt special beyond its popularity.

Re:As fast as C code???

[zuperduperman]

It's kind of a non-sensical concept because Javascript as a language is capable of things C can't do, like eval new code at run time, modify existing types etc.

By the time you have a fair comparison (ie. written C code that can really do everything Javascript can), you have basically written Javascript itself in C. So all these comparisons are really just based on getting subsets of Javascript where it is really doing no more than plain C can do to run as fast as similar plain C, and guess what, that is done more or less by compiling said Javascript to native code.

I find it amusing that all these higher level languages (everything from Java, to Javascript to Python or VB) continuously promote how they are "nearly as fast as plain C now" but then a release or two rolls by and voila they suddenly announce they have improved performance by 10x or some similar metric. But when you ask the question, "oh, so are you 10x as fast as C now?", the reply will be "oh, no, but we're nearly as fast as C!"

Re:As fast as C code???

[cbrocious]

Well, you're on the right trail, but not quite right. The key difference between Javascript and C, from an optimization standpoint, is the type system. The overhead of dynamic types is quite immense even at its most optimal. I suggest looking into the architecture of the DLR -- it really shows the key problems behind compiling dynamic languages and how they're being solved.

Re:As fast as C code???

[BZ]

For what it's worth tracemonkey is about the same speed as unoptimized C on integer math at this point. The difference is register allocation (which tracemonkey doesn't do yet).

Moving to more complicated examples, things get more interesting. Since the jit has full runtime information, it can do optimizations that a AOT compiler cannot do. At the same time, the lack of a type system does hurt, as you point out. At the moment, tracemonkey handles this by doing type inference and then if it turns out to be wrong (e.g. the type changes) bailing out and falling back on the interpreter. Turns out, types don't change much.

The real issue for a real-world Javascript program is that most of them touch the DOM too, not just execute JS. And right now tracemonkey doesn't speed that up at all. In fact, it can't jit parts of the code that touch the DOM. Eventually the hope is to add that ability.

Re:Premature optimization....

[Shados]

Considering how long Javascript has been out, and that javascript intensive applications are clearly there in the present, I don't think this is premature =P Its late!

Not bad

[neokushan]

Firefox 3 already gave quite a nice performance boost to Javascript, enough to actually impress me (google maps is a great demonstration of this). It's good to see they haven't stopped there and are busy improving it further, a lot of software developers tend to spend too much time on making new features and not enough time fixing/optimising the existing one, but I think after the backlash from FF2's memory usage, Mozilla has rethought their priorities and I'm glad to say they're doing things right.

Performance is great and all

[MasterC]

I've written my share of JS-heavy apps and the boost will be nice for that. However, my complaints with JS don't lie with performance.

• Tied too much to the browser. JS works great for some (some love it) but syntactically I hate every last part of it. However: web == JS so I have no other option.
• Typing. Yeah, it has types but they're practically worthless. A Number represents a float/double and an integer? Say what?
• Type checking.
• No reflection.
• No dictionary. Sure, you can use an Object as a dictionary but the second someone prototypes it to add root functionality then you've introduced other items in your "dictionary". (I'm looking at you prototype.js)
• Nothing resembling libraries. No dependencies, etc.
• It's bastardized to accommodate the short comings of HTML (drop downs, combo boxes, etc.)
• Obey's Postel's law too much. Error handling and exceptions is a sad state.
• No threading. No locking. Nothing resembling concurrent programming. The more complicated your app the more arbitrary events and multithreading are important.
• No classes. Prototyping & cloning is a neat paradigm for where it fits but so do class-based objects. This isn't just JS I have this problem with. Being able to do both and using the right one where necessary would be great.
• When is the document loaded? And if you have two libraries vying for that event? (See library complaint)
• Since it has no real library support I have to blame the browser for not providing more general functionality. XML parsing, date stuff is abysmal, and other "routine" stuff you do when making web sites.
• Scoping. Scoping is mind-numbingly bad.
• Namespaces (again, see library complaint) are implemented via object nesting, which isn't really namespaces
• Logging and debugging. I haven't delved into the likes of Firebug to see how it works but when the language (again no libraries so I blame the language) itself only provides alert() then it's clear the creators weren't thinking about debugging at all. At least IE natively will let you debug JS!
• Standard dialogs are alert() and confirm(). Anything and everything else you have to roll your own. I really, really don't want to write something for a Yes/No dialog instead of OK/Cancel confirm().
• Drag-and-drop. If you've done it then you know it's no walk in the park.
• Browser identification and JS version identification. Why should I have to jump through hoops, poke & prod things, and guess at what my JS run-time is? Everyone has their own means to detect it and it's absolutely ludicrous. I'm fine if there's no real "standard" but at least give me the variables to know what I'm writing against so I can adequately work with it. (Again tied too close to the browser.) Every language I use frequently has means for me to identify such things.

I think that's enough. I'm sure you could easily argue back but this is my rant about why this boost is not the saving grace to JavaScript.

Basically my point is that performance does not bring JS up another tier. It just prolongs the pain of having a grossly inadequate language for rich application development. JS does have some nice things about it (first-class functions, closures, for(..in..), etc.) but in no way would I consider it "good" for application development.

Step back and realize the movement is pushing applications into the browser. Yes, the same apps that currently use threading; the same apps that have more than 4 input widgets (input, select, radio, checkbox); the same apps that run slow even when written in native code; the same apps that depends on libraries of code; etc. JavaScript, as is, is not The Answer and this performance boost is just a Bluepill in disguise.

Fast as C but uses lots more memory

[CustomDesigned]

In general, JIT systems can really provide CPU performance near C speed, or even faster for some benchmarks, once the application gets going. The catch is that you pay two penalties: startup time and memory. Lots of memory: for keeping stats on what needs compiling, trampolines to call in and out of the interpreter vs. JIT native code, and the native code *plus* the byte code.

Even dynamic languages like Python can have a JIT - it specializes a function for various combinations of argument types, and then provides a catchall generic version for general objects. The catchall version is not much faster than the interpreter, usually (in fact it could *be* the interpreter), but the specialized versions can be much, much faster. (Also blocks can be specialized within any of the function versions.) But all those specialized versions take up memory. So the JIT keeps stats and tries to make only the ones that really help.

Re:Fast as C but uses lots more memory

[CoughDropAddict]

The catch is that you pay two penalties: startup time and memory. Lots of memory: for keeping stats on what needs compiling, trampolines to call in and out of the interpreter vs. JIT native code, and the native code *plus* the byte code.

That JITs automatically incur large memory footprint or startup time penalties is the logical conclusion you come to if you look at the JVM. But the truth is that JITs don't have to suck as much as the JVM does.

For example, take LuaJIT, a JIT for the already-speedy dynamic language Lua. It speeds up Lua roughly 2-5x while starting up in less than 0.01 CPU-seconds and introducing less than 20% memory overhead. It also takes 2-8x less memory and starts up 10x faster than the JVM, despite the fact that Lua is compiling from source, whereas the JVM starts with bytecode.

I've never looked at the source for the JVM, so I can't say just why it takes so many resources, but I can only conclude that it's because Sun just doesn't consider startup time or memory footprint a priority.

Re:Fast as C but uses lots more memory

[Mithrandir]

What's interesting is LLVM and .NET, where you can run C/C++ code in an interpreted/JIT-compiled environment. Potentially, with the optimizations mentioned above, you could have C code running in a virtual machine that's faster than statically-compiled C code.

HP did a lot of research on this about 4-5 years ago where they proved this was exactly the case. Do some googling for HP's Dynamo project. Real runtime knowledge of exactly what is being used and when leads to better optimistaion than static optimisation.

Re:The Greatest Idea

[totally bogus dude]

Sharepoint 2007 is a good example. Editing of the content is via a browser-based interface, which is quite script heavy. What's interesting is just how script heavy it is. While testing on an old laptop we have connected to an external link, I was a bit dismayed at how slow loading our site was. I got the impression that the browser was pausing before displaying the page for some reason.

Opening up task manager, I saw that before IE displayed the page, it would spin on 50% CPU (on an old hyperthreaded P4) for over 5 seconds before finally rendering the page. After some experimenting which yielded consistent results, I tried Firefox and the difference was dramatic, to say the least.

The upshot of all this is that we may need to recommend to our clients that they use Firefox to edit their Sharepoint 2007 sites, because it provides a significantly better experience than IE does if you have older hardware. On my own desktop at work (a reasonably modern Core 2 Duo) IE does spike the CPU usage, but generally it's for less than a second or two so it's not really distracting. Firefox is faster, but both are quick enough that it doesn't make a real difference to a human.

Completely off-topic: I used refreshes of the task manager process listing to judge how long IE was spinning for. I always assumed the default setting was to refresh the list once per second, and some quick testing now confirms that that is what it does. If you go to View -> Update Speed, the default setting is "Normal". The status tip for this setting says "Updates the display every two seconds". Clearly a lie - or is it? If you select "Normal", then the display does in fact update every two seconds, and there doesn't seem to be any way to get it to go back to refreshing once per second.