Firefox 18.0 Lets Loose IonMonkey Compiler

[chithanh]

I just compared the two. Firefox 18 was actually slower than Firefox 17 running Sunspider

The Sunspider benchmark is considered outdated and no longer representative of current websites, at least according to Google: http://blog.chromium.org/2011/05/upd...marks-for.html

Besides, a single synthetic benchmark doesn't necessarily tell much about the performance of IonMonkey.

[znby]

Actually gecko's clumsy codebase is the reason why firefox still does not have features like process-per-tab, and why a heavy web-app in one thread can destrroy the browsing experience of another tab (as everything is strictly single-threaded).

They have a project named Servo to replace to Gecko, they even designed their own programming language to write it in (Rust).

[Ferdinand]

I just compared the two. Firefox 18 was actually slower than Firefox 17 running Sunspider

I just compared the two. Firefox 18 was actually slower than Firefox 17 running Sunspider

You forgot the smiley.

[Calinou]

I have hundreds of tabs open in Firefox right now, in multiple tab groups . . . Chromium would fall flat on its face here.

RAM is cheap, and you don't need hundreds of tabs.

[frantaylor]

I have hundreds of tabs open in Firefox right now, in multiple tab groups . . . Chromium would fall flat on its face here.

Yeah that's how everyone browses, so running with hundreds of tabs should shoot right up to the top of the priority list. I mean how can anyone get anything done on the internet unless you have hundreds of tabs open. I hear there are REALLY cool people out there who have THOUSANDS of tabs open. Someday we will have to use 64-bit integers to describe how many tabs we can have open at once. The eventual goal is to simultaneously open every single web page on the entire internet in its own tab, all at once.

[Ferdinand]

RAM is cheap, and you don't need hundreds of tabs.

You don't need to push your preferences on other people.

[johnc]

It's amazing Javascript ever got slow as there is no reason why it can't be as fast as C code. The only thing that's slower is the type manipulation and strings, otherwise it's a very clean lower level language.

Well yeah, if you take out the fact that it's an interpreted language.

[Linuxhippy]

It's amazing Javascript ever got slow as there is no reason why it can't be as fast as C code. The only thing that's slower is the type manipulation and strings, otherwise it's a very clean lower level language.

Well, basically its all about types. With javascript you often simply don't know which type you will get, therefore you at least have to check whether you really get what you expected. This exactly what V8 does - they are proud to be able to do a property access in ~5 instructions (including a conditional jump), where with C/Java its often just a simple offset load.

Furthermore, javascript doesn't have value types, so from this perspective its very simmilar to Java. When writing real-world code, which is often more complex than some number-crunching benchmark algorithms, this really hurts. For most desktop/server projects I use Java (although I got quite a bit into C and signal processor assembly for my Diploma thesis) and take this tradeof deliberately as Java offers me way more comfort.
But the same algorithms preconditioned, for real world apps with a complex memory layout there are performance differences between C++ Java and JavaScript (in that order).

Regards