On Mon, Jul 10, 2017, at 08:29 PM, Nicholas Nethercote wrote: > Firefox now has multiple Rust components, and it's on track to get a bunch > more. See https://wiki.mozilla.org/Oxidation for details.> > 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."> > What are the obstacles? Here are some that I've heard. > > - 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?> > - ARM/Android is not yet a Tier-1 platform for Rust. See > https://forge.rust-lang.org/platform-support.html and > https://internals.rust-lang.org/t/arm-android-to-tier-1/5227 for some > details.> > - Interop with existing components can be difficult. IPDL codegen rust > bindings could be a big help.> > - Compile times are high, especially for optimized builds. > > Anything else?
Tooling around debug info in Rust code still isn't great. 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]. 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. [1] https://crash-stats.mozilla.com/report/index/2abff06f-d969-4ba5-845b-a98410170708[2] https://crash-stats.mozilla.com/report/index/03718a9c-9d98-4832-b8a6-026220170706[3] https://crash-stats.mozilla.com/report/index/6b7d1d78-8418-47ef-bee9-f49c20170710 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. 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. 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. 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. 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. 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. - Xidorn _______________________________________________ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
