
Ask HN: How much is the recent improvement in Firefox Quantum due to Rust? - lostPoncho
What kind of role did Rust play at making Firefox fast, if any at all?
======
482794793792894
The CSS engine was completely rewritten in Rust and now heavily utilizes
parallelism, which Rust certainly did help with. I'd say, this was only about
1/4 of the performance increase going from 56 to 57, though. (Based on my
perception, having run Nightly as daily driver and being aware of when which
bigger change got merged.)

The rest of the performance work was untied from Rust, as far as I'm aware.

Upcoming somewhen after 57 is also WebRender / Quantum Render, which should
give a significant boost to FPS. Basically, if you've ever wondered why your
gaming PC can render out giant space warfares at 120 FPS, but your browser
starts stuttering when that super cool menu animates itself, WebRender is
going to fix that in principle.

So, there's still going to be other problems, like JavaScript performance just
not being on par with compiled code, but it should bring us a lot closer to
the FPS that you'd expect.

(To throw in some technical terms, in case you want to research: Browsers so
far used Immediate Mode to draw things, whereas WebRender and video games use
Retained Mode.)

And WebRender was architectured as part of Servo, so is also written in Rust,
but I can't tell you, if Rust really benefitted work here, or if it just
happens to be written in Rust.

This illustrates the sort of difference we're looking at with WebRender:
[https://www.youtube.com/watch?v=u0hYIRQRiws](https://www.youtube.com/watch?v=u0hYIRQRiws)

(Mind, though, that the video is more than a year old now. Firefox 57 should
also already perform a lot better than what is shown in the video. Then again,
WebRender is VSync-capped in the video...)

------
noncoml
That’s an interesting question. Also do the Firefox engineers have any
data/feedback regarding Rust?

Was it easier to write code for the replaces parts with Rust? If yes in what
way?

Any data/metrics regarding bug counts on Rust vs C++ for the replaced
components?

~~~
482794793792894
> Any data/metrics regarding bug counts on Rust vs C++ for the replaced
> components?

Here's a funny one for the multimedia decoder:
[https://hacks.mozilla.org/2016/07/shipping-rust-in-
firefox/](https://hacks.mozilla.org/2016/07/shipping-rust-in-firefox/)

------
nwah1
Very little right now, given that so few systems are built with it. And then,
after more are converted, it will still be difficult to judge how much is a
result of the language itself, and how much is a result of improved
algorithms, gpu leveraging, and system design.

Rust itself is more about preventing bugs and security problems than improving
performance.

[https://wiki.mozilla.org/Oxidation](https://wiki.mozilla.org/Oxidation)

~~~
steveklabnik
These things are related, though. A comment by Manish, who works on Stylo:
[https://www.reddit.com/r/programming/comments/6pgdxn/stylo_s...](https://www.reddit.com/r/programming/comments/6pgdxn/stylo_servo_in_firefox_is_ready_for_community/dkpejgb/)

So yes, it's not like just writing it in Rust will make things faster. It's
that Rust makes it easier to do "improved algorithms, gpu leveraging, and
system design" in the first place.

That also said, its true that there's a lot more to 57's speed than just the
Rust work; the UI work also plays a huge part for example, given their focus
on user percepted speed related issues.

~~~
PaulHoule
For compute-heavy domains I am interested (SAT Solvers), the "Rust Tax"
doesn't seem too different from the "Managed Language Tax".

