Is there any way to make code changes work faster?

[insub]

I develop a rocket project right now. But every time I change the code, even if it's only one file, I have to wait 50s to recompile it, Is it normal to consume this time? [ cargo run --features sqlite .... Finished dev [unoptimized + debuginfo] target(s) in 53.89s ] BTW, the cargo's incremental build look like work.

Does this mean that if I modify a api or view, I have to wait 50 seconds before actually preview it on the browser? After I modify the code, I hope to preview it on the client. Is there any way to make code changes work faster?(i'm a javascript coder, i don't have compiled language work experience)

[jebrosen]

Rust is not exactly known for its fast compile times, but 50s does seem abnormally high. I personally experience closer to 5-15 seconds after changes to one of my projects using Rocket, with a Ryzen 3700U. What CPU are you running on, and what other dependencies does your project have?

[insub]

@jebrosen i working on a macbook Pro (2.4 GHz Intel Core i5) I don't know much about compiled language development environment, but if a edit & compile & test loop must wait 15s, how to develop a website base project ? Usually, we want to be able to observe the changes on the browser as soon as we finish modifying the code.( javascript / ruby)

[jebrosen]

There are two areas to consider here:

• The Rust code (the API).
  • In my experience, I have often saved time overall as compared to interpreted web servers (such as nodejs) because cargo check and cargo test find numerous problems that I would have waited until runtime to discover.
  • But yes, rust compilation is relatively slow. There are a few ways to improve time spent in this section, for example using cargo check instead of cargo build while editing code or by configuring cargo to use a faster linker such as lld. 50s is a very long time, though!
• The frontend (templates, static files, etc.)
  • If you use rocket's integration with Tera or Handlebars, template files will be automatically reloaded when they change on disk.
  • If you use a runtime template engine, several of them have built-in functionality or addons you can enable to reload templates from disk.
  • If you use a compile-time template engine, you will pay the cost at compile time as with the API code. You can sometimes reduce overall compile times by splitting templates out into a separate crate, but your mileage may vary.
  • If you use rocket_contrib::serve::StaticFiles or NamedFile (e.g. for JavaScript and static HTML assets), then you should only need to refresh the page instead of restarting the whole server.

I am not sure if that's an entirely satisfactory answer, but I hope it helps. More generally, Rust does sacrifice some up-front development time for later gains in runtime performance and time spent debugging. That is a tradeoff I am personally in favor of, but I realize it is not universally desired.

---

All that being said, 50s is a long time and worth looking into more specifically.

[insub]

@jebrosen thank you a lot, it is very helpful & clear.

After that, i rty to i set debug=0 && codegen-units=1, then run : cargo rustc --features sqlite -- -Z time-passes The compilation time reduced to 30s ! and the following tasks take a more times:

time: 12.916 expand crate time: 2.944 monomorphization collection time: 4.509 linking time: 4.560 codegen

Any suggestions?

[jebrosen]

What rustc version (rustc --version) is that with, and approximately how many lines of rust code is your project?

For a comparison point, I ran the following commands with the latest nightly (rustc 1.42.0-nightly (cd1ef390e 2020-01-31):

• cloned https://github.com/rust-lang/www.rust-lang.org
• compile it once
• touch src/main.rs
• cargo +nightly rustc -- -Z time-passes

My results are at https://paste.rs/DN0 - the most relevant ones seem to be expand_crate (0.238s), monomorphization_collector_graph_walk (0.247s), and link (5.164s).

If you would run on that repository too it would help a lot with figuring out if there is a machine or project difference accounting for those times. I could also try compiling your code as a comparison but, I do not like to assume people can make their code available.

[insub]

First thank for your help ! my rustc version is: rust version 1.42.0-nightly (d1e594f40 2020-01-22) and run cargo +nightly rustc -- -Z time-passes (www.rust-lang.org package) take about 20s. detailed info:

...
time: 1.192 expand_crate
time: 1.192 macro_expand_crate 
time: 1.350 configure_and_expand 
time: 0.215 type_check_crate
time: 0.569 crate_lints
time: 0.569 lint_checking
time: 0.667 misc_checking_3
time: 0.758 monomorphization_collector_graph_walk
time: 1.167 codegen_crate
time: 6.522 run_linker
time: 15.214    link_binary
time: 15.214    link_crate
time: 15.381    link
time: 19.607        total
    Finished dev [unoptimized + debuginfo] target(s) in 21.04s

I don't think it's a big problem, but it would be better if it could be solved.

[jebrosen]

Wow, that's a lot of time spent in the linker. It might be worth trying with lld:

RUSTFLAGS="-C link-arg=-fuse-ld=lld" cargo build

(https://www.reddit.com/r/rust/comments/dl4c8o/is_the_rust_compiler_really_that_slow/f4n7c4l/)

---

Since this seems to be a more general issue with rust and/or your environment that Rocket can't influence much, I'll close this issue. Feel free to follow up with any more findings / questions about this, though!