4 ms·
>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
by rockdoe 11y ago
>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.
- gsnedders 11y ago> 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.
- rockdoe 11y ago>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.
- RussianCow 11y agoBut 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.
- nickpsecurity 11y agoExplains why it barely handles my hundreds of bookmarks, though. Maybe I need to rewrite that part in native code haha.
- fungos 11y agoIt 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.
- nickpsecurity 11y agoI 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.
- agumonkey 11y agoChrome bookmark manager stores a lot less though.
- nickpsecurity 11y agoIs there a limit on it or something?
- agumonkey 11y agoI meant meta data, Firefox has tags and more time information IIRC, thus does more and thus is prone to be "slower".
- nickpsecurity 11y agoAhh. That makes sense.