chore: introduce --profile prod

[matklad]

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 #6226

This PR is prompted by the recent confusion about lto: https://near.zulipchat.com/#narrow/stream/345766-pagoda.2Fstorage.2Fflat-storage/topic/Migration.20plan/near/305801512

I don't think this solves the problem, but hopefully existence of --profile prod would make it more obvious?

Not super sure though, this is more like an RFC than "yes, I think we should have this"

[mina86]

Sounds like we can do --prefile prod --target-dir target? I remember I was looking into creating a prod profile a while back; don’t recall why we didn’t go with it then. Another option would be to build in target/prod directory and then symlink executables to target/release

[mina86]

Ah, no, that was you: #6226

[mina86]

And again, no, --target-dir won’t do. It’s again issue with --out-dir being unstable.

[matklad]

Yeah, I also think there's sadly no great solution here. The way I think about it, --profile prod is the way to build the right binary, and for Makefile we need to use a work-around. Two work-arounds which would work:

• export and use -r
• --profile prod and linking afterwards

I would say first-best solution is to put stuff in ./target/neard, so that we are not dependent on Cargo's layout (eg, if we decide to cross-compile stuff today, we'd also observe different target layout).

But this ideal world obviously won't fly as everyone is already depending on stuff being in ./target/release.

[mina86]

I’m +0 on this one.

[mina86]

Worth to mention that the binary will end up in target/prod

[jakmeier]

Hm, for me personally this is a useful change because I often set these env variables manually when benchmarking.

But if we add this profile and keep everything as it is, it seems we make the overall infra more complicated with duplication of optimization flags, for a small convenience in return. And one still has to remember that --release is not fully optimized. I am not convinced it is worth it.

I wonder, is there a way we can introduce this new profile and make it the new recommended way to build the production binary? The Makefile target could still produce a binary at target/release but maybe we could deprecate it, so that new tools at least will uses the prod profile?

[mina86]

I wonder, is there a way we can introduce this new profile and make it the new recommended way to build the production binary? The Makefile target could still produce a binary at target/release but maybe we could deprecate it, so that new tools at least will uses the prod profile?

There are three ways. One is that we could use --out-dir parameter for cargo. Unfortunately, that flag is unstable so for the time being it’s arguably not a viable solution. The other way is that we add linking or copying step to Makefile which copies executables from target/prod to target/release. This removes duplication at the cost of complicating Makefile a little. The last option is to just enable full optimisation for --release build and make it so that disabling optimisation requires setting the flags. Here the question is how many people use --release wanting a not fully optimised binary.

[jakmeier]

Enabling full optimization for a release build seems the cleanest to me. We can also add --profile fast (name up for debate) that has the same semantics as the current release build. (no LTO = fast compilation and fast-but-not-production-ready binary)

Here the question is how many people use --release wanting a not fully optimised binary.

Hopefully the number is small enough that we can convince them all to either wait a bit longer or switch to the new profile.

[matklad]

Makes sense, flipped the approach to introduce a --quick-release profile.

@jakmeier could you make a judgement call here? I feel your expertise is the best to own our optimization settings

[matklad]

16 is the default Cargo's setting for -r

[mina86]

https://github.com/near/node-docs/blob/7e8fcd38d9bd5b3ef89bfb2689497fdf4f5df06b/docs/rpc/run-rpc-node-without-nearup.md et al and maybe near/docs@8b4c920#diff-3af802c9a99e1715d99dd3ca33c5dc6812ab74a11b1a679e225eddfe9685e0dd might also need some updating (though I cannot find where the second document now lives).

[matklad]

might also need some updating (though I cannot find where the second document now lives).

The second document is now the fast_builds.md, updated in this PR

[matklad]

near/node-docs#57

[jakmeier]

Yes I think we should do it. Then --release actually produces a release build.
But we should probably announce it in a Zulip channel so people can update their workflow instead of being confused about super slow compilation time on -r. (can be done after merging IMO)

Otherwise, worst case that can happen, I think, is some automated setup starts timing out. That's a risk we can take.

---

In this PR or a follow-up: Remove this now obsolete code from the params-estimator main.rs

if full {
    cmd.args(&["--env", "CARGO_PROFILE_RELEASE_LTO=fat"])
        .args(&["--env", "CARGO_PROFILE_RELEASE_CODEGEN_UNITS=1"]);
}

[matklad]

https://near.zulipchat.com/#narrow/stream/295302-general/topic/PSA.3A.20cargo.20profile.20changes