<!DOCTYPE html>
<html>
<head>
<title></title>
</head>
<body><div>On Mon, Jul 10, 2017, at 08:29 PM, Nicholas Nethercote wrote:<br></div>
<blockquote type="cite"><div dir="ltr"><div>Firefox now has multiple Rust components, and it's on track to get a bunch more. See <a href="https://wiki.mozilla.org/Oxidation">https://wiki.mozilla.org/Oxidation</a> for details.<br></div>
<div><br></div>
<div>I think this is an excellent trend, and I've been thinking about how to accelerate it. Here's a provocative goal worth considering: "when writing a new compiled-code component, or majorly rewriting
an existing one, Rust should be considered / preferred / mandated."<br></div>
<div><div><br></div>
<div>What are the obstacles? Here are some that I've heard.<br></div>
<div><br></div>
<div>- Lack of Rust expertise for both writing and reviewing code. We have some pockets of expertise, but these need to be expanded greatly. I've heard that there has been some Rust training in the Paris and Toronto offices. Would training in other offices (esp. MV and SF, given their size) be a good idea? What about remoties?<br></div>
<div><br></div>
<div>- ARM/Android is not yet a Tier-1 platform for Rust. See <a href="https://forge.rust-lang.org/platform-support.html">https://forge.rust-lang.org/platform-support.html</a> and <a href="https://internals.rust-lang.org/t/arm-android-to-tier-1/5227">https://internals.rust-lang.org/t/arm-android-to-tier-1/5227</a> for some details.<br></div>
<div><br></div>
<div>- Interop with existing components can be difficult. IPDL codegen rust bindings could be a big help.<br></div>
<div><br></div>
<div>- Compile times are high, especially for optimized builds.<br></div>
</div>
<div><div><br></div>
<div>Anything else?<br></div>
</div>
</div>
</blockquote><div><br></div>
<div>Tooling around debug info in Rust code still isn't great.<br></div>
<div><br></div>
<div>The first thing comes to my mind is crash reports. It currently
doesn't always include useful panic message from Rust, see for example
[1] and [2]. Also for Stylo, we generate lots of code (including using
bindgen and mako template system, bindgen is usually fine, but the code
generated from template can contain lots of code logic), and when the
crash happens inside generated code, it is pretty hard to understand
what's going wrong, because there is no useful source link, see for
example [3].<br></div>
<div><br></div>
<div>There are also issues from Rust side. I've always been using an
optimized debug build locally (because that runs faster), and sometimes
use Visual Studio to investigate issues. C++ code works fine with this
configuration, but in Rust code, I cannot see any variable information.
Stack backtrace seems to work fine to me, though.<br></div>
<div><br></div>
<div><div><div>[1] <a href="https://crash-stats.mozilla.com/report/index/2abff06f-d969-4ba5-845b-a98410170708" defang_rel="noopener noreferrer">https://crash-stats.mozilla.com/report/index/2abff06f-d969-4ba5-845b-a98410170708</a><br></div>
</div>
<div>[2] <a href="https://crash-stats.mozilla.com/report/index/03718a9c-9d98-4832-b8a6-026220170706" defang_rel="noopener noreferrer">https://crash-stats.mozilla.com/report/index/03718a9c-9d98-4832-b8a6-026220170706</a><br></div>
<div>[3] <a href="https://crash-stats.mozilla.com/report/index/6b7d1d78-8418-47ef-bee9-f49c20170710" defang_rel="noopener noreferrer">https://crash-stats.mozilla.com/report/index/6b7d1d78-8418-47ef-bee9-f49c20170710</a><br></div>
</div>
<div><br></div>
<div><br></div>
<div>Besides tooling, not just compile time, but also the link time is
high. Specifically, I suspect our linking strategy for Rust code doesn't
interact well with MSVC's incremental linker, which slows down this
final sequential step.<br></div>
<div><br></div>
<div>For that, I just did an experiment. In my local repo, when I remove
all linking-related files from objdir/toolkit/library (to do a fresh
linking), it takes ~1.7min for linking.<br></div>
<div><br></div>
<div>When I touch one cpp file (in my experiment,
layout/style/nsCSSAnonBoxes.cpp which is a reasonable small cpp file I
happen to open), it takes 6s to link, and size of xul.ilk (Incremental
Linker File) increases by 856KB.<br></div>
<div><br></div>
<div>When I touch one rs file (in my experiment,
servo/components/gecko_bindings/sugar/style_complex_color.rs which is a
reasonable small rs file I happen to be familiar with), it takes ~2min
to link (even longer than the fresh linking!) in addition to the compile
time, and size of xul.ilk increases by 27.44MB. And after that, when I
touch that cpp file again, it takes ~2.1min to link and size of xul.ilk
increases by 54.64MB this time.<br></div>
<div><br></div>
<div>I suspect the more times you touch rs files, the longer linking
would take, and I guess this is because we link all Rust code into a
single library, and then static link it into xul.dll, which makes the
linker do lots of wasteful work. There could also be some linker bug
involves, though.<br></div>
<div><br></div>
<div>To mitigate this, we can probably avoid incremental linking when
Rust code is touched. I also wonder if it is possible to avoid linking
the whole gkrust into xul.dll at all and see if that makes things
better. It would also be good to see if Rust developers have any advice
for this situation.<br></div>
<div><br></div>
<div><br></div>
<div>- Xidorn<br></div>
</body>
</html>