chore: reshuffle build profiles

As of this commit:

* `--release` is a production profile with full-lto
* `--quick-release` is what the old `--release` was: all optimiations
  except for lto.

cc near#6226

Cargo.toml

@@ -207,12 +207,21 @@ xz2 = "0.1.6"
 # "test" profile inherits from "dev" profile.
 # https://doc.rust-lang.org/cargo/reference/profiles.html#test
 
+[profile.dev]
+panic = 'abort'
+
 [profile.release]
 overflow-checks = true
 panic = 'abort'
+lto = "fat"
+codegen-units = 1
+
+# A much faster to compile version of `release`.
+[profile.quick-release]
+inherits = "release"
+lto = false
+codegen-units = 16
 
-[profile.dev]
-panic = 'abort'
 
 # Compile some dependencies with optimizations to speed up tests.
 [profile.dev.package.hex]

Makefile

@@ -1,5 +1,3 @@
-export CARGO_PROFILE_RELEASE_CODEGEN_UNITS = 1
-export CARGO_PROFILE_RELEASE_LTO = fat
 export DOCKER_BUILDKIT = 1
 export CARGO_BUILD_RUSTFLAGS = -D warnings
 export NEAR_RELEASE_BUILD = no

docs/practices/fast_builds.md

@@ -13,15 +13,17 @@ contains a section on compilation time as well!
 
 ## Release Builds and Link Time Optimization
 
-Obviously, `cargo build --release` is slower than `cargo build`. What's not
-entirely obvious is that `cargo build -r` is not as slow as it could be: our
-`--release` profile is somewhat optimized for fast builds, as it doesn't enable
-full LTO.
-
-When building production binaries, we use `lto=true` and `codegen-units=1`
-options, which make the build significantly slower (but the resulting binary
-somewhat faster). Keep this in mind when running benchmarks or parameter
-estimation.
+Obviously, `cargo build --release` is slower than `cargo build`. We enable full
+lto (link time optimization), so our `-r` builds are very slow, use a lot of
+RAM, and don't take advantage full of parallelism.
+
+As debug builds are much to slow at runtime for many purposes, we have a custom
+profile `--profile quick-release` which is equivalent to `-r`, but doesn't do
+`lto`.
+
+Use `--profile quick-release` when doing comparative benchmarking, or when
+connecting a locally build node to a network. Use `-r` if you want to get
+absolute performance numbers.
 
 ## Linker
 

runtime/runtime-params-estimator/src/main.rs

@@ -306,6 +306,7 @@ fn main_docker(
     json_output: bool,
     debug: bool,
 ) -> anyhow::Result<()> {
+    let profile = if full { "release" } else { "quick-release" };
     exec("docker --version").context("please install `docker`")?;
 
     let project_root = project_root();
@@ -340,15 +341,17 @@ fn main_docker(
         #[cfg(feature = "nightly_protocol")]
         buf.push_str(",nightly_protocol");
 
-        buf.push_str(" --release;");
+        buf.push_str(" --profile ");
+        buf.push_str(profile);
+        buf.push_str(";");
 
         let mut qemu_cmd_builder = QemuCommandBuilder::default();
 
         if debug {
             qemu_cmd_builder = qemu_cmd_builder.plugin_log(true).print_on_every_close(true);
         }
-        let mut qemu_cmd =
-            qemu_cmd_builder.build("/host/nearcore/target/release/runtime-params-estimator")?;
+        let mut qemu_cmd = qemu_cmd_builder
+            .build(&format!("/host/nearcore/target/{profile}/runtime-params-estimator"))?;
 
         qemu_cmd.args(&["--home", "/.near"]);
         buf.push_str(&format!("{:?}", qemu_cmd));