Debugging and maybe profiling in Visual Studio 2019

Editors and IDEs
1

A while back I debugged/profiled a Rust project in Visual Studio 2019 as a test, and the other day someone at the office needed to profile some code. I said it was easy, but couldn't remember some of the steps (in particular that once can load an executable as a "project" in VS2019). So this time I'll document it here in case I forget the details next time I need it, and hopefully it'll be useful to others.

Note: There are bugs in Windows/Visual Studio which cause profiling not to work on some computers. If these instructions don't work, it's likely due to these bugs.

Start by creating an application project:

cargo new --vcs none --bin vstest

Add to Cargo.toml :

[dependencies]
hashbrown = { version = "0.11" }

Within vstest , populate src/main.rs with:

fn main() {
  std_add();
  hashbrown_add();

  std_add_remove();
  hashbrown_add_remove();
}

fn std_add() {
  let mut map = std::collections::HashMap::new();
  for i in 0..65536 {
    map.insert(i, i);
  }
}

fn hashbrown_add() {
  let mut map = hashbrown::HashMap::new();
  for i in 0..65536 {
    map.insert(i, i);
  }
}

fn std_add_remove() {
  let mut map = std::collections::HashMap::new();
  for i in 0..65536 {
    map.insert(i, i);
  }

  for i in 0..32768 {
    map.remove(&i);
  }
}

fn hashbrown_add_remove() {
  let mut map = hashbrown::HashMap::new();
  for i in 0..65536 {
    map.insert(i, i);
  }

  for i in 0..32768 {
    map.remove(&i);
  }
}

// vim: set ft=rust et sw=2 ts=2 sts=2 cinoptions=2 tw=79 :

For profiling release builds, add to Cargo.toml :

[profile.release]
debug = 1

Now build project:

cargo build
cargo build --release

To get a somewhat ergonomic experience while debugging:

  • Don't move any of the source or target files.
  • Don't modify any of the source or target files.

Open up Visual Studio 2019 and select Open a project or solution (oddly enough this allows opening up executables as well).

Change the filter to Exe Project Files (*.exe) and then browse to whichever (debug/release) version of vstest.exe you want to debug/profile and open it.

Open the vstest's main.rs file by clicking File -> Open -> File ... , browse to the file, select it, and click Open .

Create a breakpoint on the call to std_add() and the final } in main() .

Select Debug -> Windows -> Show Diagnostic Tools . In the Diagnostic Tools pane, drop down Select Tools and make sure that CPU Usage is checked. Then click the Record CPU Profile .

Note: The profiler will profile between breakpoints.

Now start debugging (F5). You may get an erroneous warning about the source being changed, but this is just Visual Studio being Visual Studio.

Visual Studio will break at the breakpoint. Now you can do the regular debuggning things, like stepping and inspecting.

If you continue (F5) you might get CPU Profiling generation. The "might" qualifier is there because these things are horribly broken in Windows/Visual Studio. See this thread/post about profiling bugs. This thread links to this PR which indicate that the bug is fixed, which - if true - means there's another bug. There's also another PR which is currently "Under investigation" which could possibly fix the issue.

In short: Visual Studio profiling will work on some computers, and if it doesn't there may be a few weird workarounds, but no guarantees.

Edit: We tried running the profiler on four different Windows systems here at the office and it only works on one of them. If you read this and are willing to try it, please do and post your results.

2

This topic was automatically closed 90 days after the last reply. We invite you to open a new topic if you have further questions or comments.