> Given that most of Firefox is in JS so the actual code that you end up running is the JIT output, I'd be very skeptical it's any faster.

Most of Firefox is JS? Almost all of the lines of code are C++, as far as I'm aware. Certainly the UI is drawn using XUL/XBL/web-stuff, but how often is web performance bounded by UI performance? It's bounded by the performance of the rendering engine, and that is C++.

> (And if it were, I'd assume Mozilla would just Intel C for the official builds, too?)

Seems unlikely, given the output of ICC is crippled for non-Intel x86 chips (which de-facto means AMD nowadays).

>Almost all of the lines of code are C++

Significant parts of the functionality are written in JS.

>but how often is web performance bounded by UI performance?

It's often bounded by JS performance. JS performance depends on the JIT output, much less so the speed with which the JIT itself runs.

The rendering engine may be a factor, but there HW acceleration also factors in. It's far from being clear cut.

Media decoding already uses optimized assembler, nothing for the compiler to do there.

I'd suppose most of the gain would be in layout?

>Seems unlikely, given the output of ICC is crippled for non-Intel x86 chips (which de-facto means AMD nowadays).

You can patch that out. I'd hope this Waterfox is doing that...

Even so, Mozilla provides a stub installer that downloads the right binary nowadays. It could check the chip vendor and get the appropriate binary.

> Significant parts of the functionality are written in JS.

Such as?

> It's often bounded by JS performance. JS performance depends on the JIT output, much less so the speed with which the JIT itself runs.

On what? Last I looked, even things like FB & Gmail are largely bound by performance of C++ code. Sure, there's a few hot JS functions high-up in the profiles (esp. in the large data structures they build up when initially loading), but by and large time is spent in C++ code, not JS.

>Such as?

Looks for .js and .jsm in the source tree.

Bookmarks, Tab management, all UX, PDF viewer, Search, Prefs, Sync, parts of SafeBrowsing, WebRTC, Update Handling, Login and Form manager, Devtools, Reader Mode, and uh I think I've proven my point.

But none of those things will ever really bottleneck the browser except for maybe the PDF viewer. The performance of bookmarks, tab management, search, and basically all your other examples doesn't matter. The parts of the browser that benefit from speed are written in C++.

Not that I'm convinced simply compiling with ICC will actually have a noticeable impact on the day-to-day performance of the browser, but it might speed up layout and other specific CPU-bound tasks. I'd love to see some benchmarks, but I think it's silly to shrug it off by saying that it won't matter because the browser UI is written in JavaScript.

Explains why it barely handles my hundreds of bookmarks, though. Maybe I need to rewrite that part in native code haha.

It seems a joke but is also, sadly, a fact. Chrome bookmarks manager is lightspeed if compared to Firefox, to not mention total lack of usability on Firefox's part, so 1995.

I was against them writing significant portions of Firefox in Javascript from the beginning. Maybe a generator from JS to native for templating interfaces or something. I could see some compromise to aid the web crowd in extending Firefox. Shouldn't be what's running, though, given the inefficiency.

Chrome bookmark manager stores a lot less though.

Is there a limit on it or something?

I meant meta data, Firefox has tags and more time information IIRC, thus does more and thus is prone to be "slower".

Ahh. That makes sense.

It sounds very much like a quality of implementation issue. There's no good reason why you can't deal with ten of thousands of bookmarks in JS with good performance.

Possibly but why would you want to in an app mostly written in efficient, native code? The typical reason for scripting engines is easier configuration by users or less skilled programmers. So, the user interface made a bit of sense being JS. All this other stuff that mostly stays the same? Not so much.