Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

cargo bench --no-run uses release profile #4240

Closed
joliss opened this issue Jun 29, 2017 · 6 comments · Fixed by #6309
Closed

cargo bench --no-run uses release profile #4240

joliss opened this issue Jun 29, 2017 · 6 comments · Fixed by #6309
Labels
A-profiles Area: profiles C-bug Category: bug Command-bench

Comments

@joliss
Copy link

joliss commented Jun 29, 2017

I have the following snippet in my Cargo.toml:

[profile.bench]
debug = true # for profiling

However, when I run cargo bench --no-run, the binary that is placed in
target/release/benches-* does not seem to contain debug information.

Only when I add the following snippet do I get debug information:

[profile.release]
debug = true
@alexcrichton
Copy link
Member

cc @matklad, more oddness with profiles!

@anderejd
Copy link

anderejd commented Oct 11, 2018

@joliss Thank you!! My blood pressure were approaching rage quit levels here right before finding this 😆


~~~I'm on stable Rust 1.29.1 in combination with [Criterion](https://github.com/japaric/criterion.rs).~~~

~~~Removing `--no-run` and having at least one criterion benchmark execute normally before trying to launch the benchmark executable from dtrace does provide a workaround.~~~

EDIT: It turned out to be a script failure unrelated to cargo.

@ehuss ehuss added the A-profiles Area: profiles label Oct 11, 2018
@ehuss
Copy link
Contributor

ehuss commented Oct 11, 2018

@alexcrichton I hadn't really thought of it, but it does seem surprising that dependencies use dev/release profiles even when benching/testing. Is that really intended?

@anderejd I'm surprised that --no-run makes any difference, as all that does is avoid running the executable. Can you provide a sample project and a list of steps to run dtrace to exhibit the lack of stack information?

@anderejd
Copy link

@ehuss It seems like I was mistaken. It was a silent failure of my dtrace script that produced empty output, nothing related to cargo. Sorry for the noise.

@alexcrichton
Copy link
Member

@ehuss I believe that was done historically to ensure that cargo build followed by cargo test didn't recompile everything, although the way of using entirely different profiles was probably a big enough hack that it wasn't really that necessary at the time and is a bit too codified now :(

bors added a commit that referenced this issue Nov 14, 2018
Use "test" profile for `cargo build` benchmarks.

When using `cargo build` (without `--release`), build benchmarks using the "test" profile. This was causing some confusion where the benchmark is placed in the `target/debug` directory, and also causing some duplicates that may not be expected. It also makes it easier to debug benchmarks (previously you had to edit the `[profile.bench]` profile).

Closes #5575, closes #6301, closes #4240, closes #4929.
@LightAndLight
Copy link

This is the closest thing I could find to my current problem.

Running cargo bench with

[profile.bench]
debug = true

produces bench binaries without debug symbols.

Running cargo bench with

[profile.release]
debug = true

produces bench binaries with debug symbols.

I'm using perf record -g to observe the (lack) of debug symbols.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-profiles Area: profiles C-bug Category: bug Command-bench
Projects
None yet
Development

Successfully merging a pull request may close this issue.

5 participants