5 comments

[ 4.4 ms ] story [ 28.6 ms ] thread
It's interesting that they're taking from Apple's Nitro (formerly SquirrelFish) rather than from Chrome's V8. If both Javascript engines are open source, and Chrome is generally regarded as the fastest (beating out Safari by at least a hair in most cases), I wonder what factors made them choose to adopt from Apple over Google?
Perhaps because V8's engine translates directly from code to assembly with no intermediate bytecode. It seems like it would make it more difficult to integrate tracing with that system.
Having an intermediate bytecode also makes it easier to support more architectures in a reasonably consistent manner: for architectures where you don't have a bytecode->asm compiler, you can fall back on interpreting the bytecode (as TraceMonkey currently does).

With V8, the direct targeting of architecture-specific asm means you have no support at all on architectures that V8 doesn't yet target--- or you'd have to support them through a different Javascript stack entirely, like falling back to TraceMonkey, which would be harder to keep consistent.

Of course, Mozilla could go the Chrome route and drop support for everything except x86, x86-64, and ARM. But for the moment at least, they appear interested in keeping at least the Linux version available on PowerPC, SPARC, and other architectures.

They are probably under more pressure now that Opera has come out with a fast Javascript engine in 10.50.
As has been pointed out here many times (e.g. http://news.ycombinator.com/item?id=1132721), Firefox's performance problems have to do with DOM and rendering, not JS execution. They continue to pour effort into optimizing the wrong thing, perhaps because that's where the benchmarks and bloggy coolness are. The old joke comes to mind about the drunk looking for his car keys under the street lamp, instead of where he dropped them, "because the light's better here"...