Firefox 18.0 Lets Loose IonMonkey Compiler

[mayankleoboy1]

Ok, lets talk about threads. As threads share the same process space, there is no real disadvanatge to use multiple threads - however, Firefox has an inherently single-threaded rendering model/engine.
Using multiple threads would allow multicore-CPUs to shine, and it would reduce the amount of stutter when one tab taxes the CPU,

Every rendering model/engine is single threaded. Even webkit/chrome/safari.
What they do have is one process per tab, which Firefox lacks.

AFAIK, only Mozilla is working on a true multithreaded rendering engine. Its the mozilla Servo.

[Ferdinand]

Actually the javascript disaster of Firefox is an example of really poor management.
I can't remember how often the code-generation stage got completely rewritten in the last couple of yours, and now basically they end up with something similar to V8 (developed by google).

For me the big question actually is:
- Why not opt for a clean design in the first place? Compiling dynamically typed languages is not something that has not been there before...
- Why not use the code developed by google? V8 simply is the fastest javascript runtime, and its open-source
The same basically goes for gecko. Why develop everything by yourself, when you can get it for free elsewhere. 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).

However, I still use FireFox as its graphic rendering engine based on Cairo is painting web-pages at light velocity when using intel's SNA drivers =)

Why ask those questions here when you can just google it and find the answer?
In short: Mozilla's developers learn and the javascript engine gets better, ionmonkey is a clean design, jeagermonkey is a clean design, monopolies are bad
And calling gecko's codebase clumsy... Wow you got a lot of nerve.

[Ferdinand]

The problem with Firefox is not 'speed'. Well, not speed by their definition. The Mozilla team defines 'speed' in the sense of bandwidth: how many operations/second the browser is capable of bringing. This is the wrong definition for most users.

What the users talk about when they say 'speed' is actually latency, not bandwidth. I couldn't care less about the bandwidth of the JavaScript engine most of the day since I don't play games etc in the browser. What I do care about is the amount of time it takes to load a web page. This is 'latency', that is how long it takes from clicking a link to the page being fully rendered. In this test Chrome wins hands down.

Another very big problem with Firefox is that there is no true separation between tabs. Several times a day it happens that I open a few tabs in the background, only to get Firefox unresponsive due to one of the tabs behaving badly. This is unacceptable. In Google's Chrome tabs are separated to different processes and the browser never becomes unresponsive.

Mozilla should fix the real problems, not some niche geeky problems. If they don't they will continue to loose market share in an alarming rate.

You should read up on project snappy which has been going for 18 months. (if you really cared you would have known about it) There you can also read why you are wrong about true separation of tabs being the answer to snappy design.

[Ferdinand]

Furthermore, when looking at the +500mb RSS memory allocated by my currently running FF instance, I don't believe memory savings were the main motivation here ^^

Post your about:memory
(If you complain about Firefox memory usage you should really post about:memory it is a much better way of complaining and explains a lot)

[mayankleoboy1]

Furthermore, when looking at the +500mb RSS memory allocated by my currently running FF instance, I don't believe memory savings were the main motivation here ^^

Can you do this : type "about:memory?verbose" without the quotes in the URL bar, and post it here : https://blog.mozilla.org/nnethercote/


And i do think FF uses lesser memory than Chrome for my workload. I opened ~800 images from a page. Chrome Out-of-memoried. Firefox got major hangs during loading. But once loaded, it had no problem.

[e8hffff]

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.

[Veerappan]

Post your about:memory
(If you complain about Firefox memory usage you should really post about:memory it is a much better way of complaining and explains a lot)

Thanks for that reference... I've never known about/used that info page, but as a web developer I'm sure it'll come in useful in the future.

[amehaye]

You should read up on project snappy which has been going for 18 months. (if you really cared you would have known about it) There you can also read why you are wrong about true separation of tabs being the answer to snappy design.

Snappy is indeed relevant to the first part of my rant. However with regard to the second part (process separation) project Electrolysis is more relevant: https://wiki.mozilla.org/Electrolysis


Unfortunately this project seems to have been abandoned: http://lawrencemandel.com/2011/11/15...s-development/

This is more important to me than sheer performance. I usually open several links in the background, so the actual time it takes to render is irrelevant. What *is* relevant is the fact that I actually have to wait for them to render since Firefox is a single process application. If firefox was a process-per-tab application, with another process for the UI, I could open new tabs while waiting for the old ones to render. Also, stuck tabs would not freeze Firefox. This is the single most important feature that Firefox is lacking and will probably be lacking in the near future.

[Ferdinand]

Snappy is indeed relevant to the first part of my rant. However with regard to the second part (process separation) project Electrolysis is more relevant: https://wiki.mozilla.org/Electrolysis


Unfortunately this project seems to have been abandoned: http://lawrencemandel.com/2011/11/15...s-development/

This is more important to me than sheer performance. I usually open several links in the background, so the actual time it takes to render is irrelevant. What *is* relevant is the fact that I actually have to wait for them to render since Firefox is a single process application. If firefox was a process-per-tab application, with another process for the UI, I could open new tabs while waiting for the old ones to render. Also, stuck tabs would not freeze Firefox. This is the single most important feature that Firefox is lacking and will probably be lacking in the near future.

You read my first sentence. Now go read the second please.

[fuzz]

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