chore: introduce --profile prod

This solves two problems:

* Makes it easy to produce a fully-optimized binary when doing
  lto-sensitive benchmarking
* Makes it simpler for the estimator to build the binary with the right
  optimizations, by avoiding hard-coding config into the estimator.

Ideally, we'd change the Makefile as well, but we'd rather not break
existing `./target/release` layout.

In other words, before we had two sources of truth: Makefile and
estimator. Now they are Makefile and Cargo.toml, and we also gained a
nice cli flag for building fully optimized version:

$ cargo b --profile prod -p neard --bin neard

cc near#6226

Cargo.toml

@@ -206,12 +206,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'
 
-[profile.dev]
-panic = 'abort'
+# Excruciatingly slow to compile, but faster.
+#
+# This mirrors the settings from the Makefile to produce official binaries,
+# though Makefile doesn't use this profile for obscure compatibility reasons.
+[profile.prod]
+inherits = "release"
+lto = "fat"
+codegen-units = 1
 
 # Compile some dependencies with optimizations to speed up tests.
 [profile.dev.package.hex]

Makefile

@@ -1,5 +1,10 @@
+# Enable `lto`.
+#
+# This is equivalent to `--profile prod`, but keeps the resulting binary in
+# `./target/release/neard`, to not break historical infra relying on that.
 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

@@ -23,6 +23,16 @@ options, which make the build significantly slower (but the resulting binary
 somewhat faster). Keep this in mind when running benchmarks or parameter
 estimation.
 
+To produce a fully optimize, production binary, run
+
+```console
+$ cargo build --profile prod -p neard --bin neard
+```
+
+It's also a good idea to consult our
+[Makefile](https://github.com/near/nearcore/blob/64be192a1c3b224172cd2f1525fbf18e1e5e2691/Makefile)
+-- that it is a source of truth for how release binaries are prepared.
+
 ## Linker
 
 By default, `rustc` uses system's linker, which might be quite slow. Using `lld`

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

@@ -305,6 +305,7 @@ fn main_docker(
     json_output: bool,
     debug: bool,
 ) -> anyhow::Result<()> {
+    let profile = if full { "prod" } else { "release" };
     exec("docker --version").context("please install `docker`")?;
 
     let project_root = project_root();
@@ -339,15 +340,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));