0

I have a small Qt project written in c++ and when i debug it (Release) its taking like 7~10sec to start, even with the cache symbols saved into a local folder.

When I disable this option: Debugging -> General -> [x] Load debug symbols in external process (Native only)

And select this option: Debugging -> Symbols -> (*) Load only specified modules

It take around 1sec to start debugging the same project.

My computer specs:

Windows 10
Visual Studio 2022
cpu: i9 9900k
ssd: 970 evo plus (gen3 around 2~3k read/write speed)

Why such difference in time?

I'm asking because even 'disabling' the options i mentioned, intellisense is still working.

What are these symbols used for when debugging?

Does disabling these options impact in something when not debugging?

Cesar
  • 41
  • 2
  • 5
  • 16
  • Debugging symbols are used when running the progam under the debugger and include every variable name and type used in the entire program, for all scopes, storage classes, external modules etc; ie a lot of information. – Richard Critten Dec 20 '22 at 14:40
  • @RichardCritten So is it used only when debugging? – Cesar Dec 20 '22 at 14:43
  • Experiment with anti-malware, but turn on only when necessary: https://devblogs.microsoft.com/cppblog/out-of-process-debugger-for-c-in-visual-studio-2019/ – Hans Passant Dec 20 '22 at 17:58
  • @HansPassant i dont have any anti-malware, inclusive windows defender is disabled on policy – Cesar Dec 20 '22 at 19:11
  • I suggest you to read these issues, it will help you. [LINK1](https://stackoverflow.com/questions/3377720/visual-studio-loading-symbols) [LINK2](https://stackoverflow.com/questions/17660368/visual-studio-debugging-painfully-slow-when-loading-symbols) – Yujian Yao - MSFT Dec 21 '22 at 01:50

1 Answers1

0

After the source code has been compiled, most of the actual names of variables will be stripped out to save space, because the actual machine code of the executable doesn't use the long string names of variables, it uses memory addresses.

So debugging symbols are used to provide information to the debugger which normally wouldn't be present in the final executable. Such as the names you provided in the source code to associate with various memory addresses. So if an error occurs, such as:

int* some_invalid_pointer = NULL;
// Segmentation fault should occur here
int some_variable = *some_invalid_pointer;

If you don't have debug symbols enabled, you may get a message such as Error: Segmentation Fault because the debugger has no idea what the name of each variable actually is. Debugging symbols give the debugger more information so it could print a message closer to Error: Segmentation Fault on Line 3: "int some variable = *some_invalid_pointer;" which is much easier to debug.

So it takes longer both because of the larger size of the executable needing to be loaded, and because debugging isn't as simple as running a version of the code compiled in debug mode. Debugging usually consists of running an actual separate Debugger executable, which then loads and runs your code. So when debugging you actually need to load and start running the Debugger, then the Debugger loads your program, which is especially slow because it could be the debugger loading it and not the OS like normal.

(To answer your final question, yes technically debugging info can be left in a release executable, but because of the way executables are usually Demand Paged into memory (You can look it up if you're interested), basically what it means is that info within an executable which is never actually referenced, shouldn't ever be loaded into memory and so it shouldn't have an impact on release runtime performance)

kjhayes
  • 143
  • 7