Jump to content
  • Advertisement
Sign in to follow this  
ViperG

VS 05 Runtime dll's & Debug Breaks

This topic is 4327 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

First question is What's the difference between /MT and /MD that I need to know about when making a game. Currently I'm compiling /MT so I don't need the manifest files and don't need to include any of the runtime dll's. However, MD does decrease my exe file of course, but then i need to include those 2 dlls. MSVCP80.DLL and MSVCR80.DLL Is there any trick or method I can do so I don't need those runtime dlls, or just stay with /MT My other off subject question is when im in debug mode, and I do a Break All command, and in the stack im in NT.DLL.... which is totally useless for me. I changed the options to debug my code only, but it still shows up under nt.dll. http://msdn2.microsoft.com/en-us/library/h5e30exc.aspx "Programmatic break statements, such as Visual Basic Stop statements, are handled differently. The debugger always breaks on these statements, even when Just My Code is enabled. In this situation, non-user code is displayed rather than hidden, but stepping will still take you out of non-user code to the next line of My Code." If I understand that correctly, all I have to do is step out, and i should be back in my code, but it doesn't seem to work, im still in kernel or nt.dll...

Share this post


Link to post
Share on other sites
Advertisement
I believe you need a manifest file to compile a project in release mode. Those two DLLs help you compile your code for release. Make sure you're compiling in Debug mode if that's what you want.

When it comes to doing breaks in my code, I just set breakpoints. In the end, it's probably less of a hassle than dealing with whatever craziness VS will throw at you.

Share this post


Link to post
Share on other sites
Have you looked at the call stack?

It is quite possible the app is idleing, and the point of execution actually is in NT.dll without being in your code.

Share this post


Link to post
Share on other sites
Yeah it depends when i break, but usually i just see dll calls and thats it.

But it does show my exe using 99% cpu in task manager. And i get about 120 fps in the game.

i heard that its an easy way to find out the slowest part of your code, just break 5 times, and whatever is in the call stack the most is probably a slow function, because most likely 90% of the time you should break in it etc.

Profiling doesn't seem to give me that much information(I tried the amd one), and i don't feel like putting timers on all my funcitons to see for my self.

id would be nice if they made a profiler that you can make it list only direct in code function calls, Or even better, have it detect all the functions, then you can just run a profiler for say 10 of your functions you want to test. as in you just select them from a gui menu then hit profile. most profilers give you all the code and most of it i don't need to see. I just need the top 10 slowest functions or areas of code. /rant off

[Edited by - ViperG on October 16, 2006 2:31:53 PM]

Share this post


Link to post
Share on other sites
yeah it visual studio 2005 the call stack is automaticly visible when your debugging.

I just hate it when i break that it mostly ends up in some dll that i don't care bout. Whenever that happens i have no symbols and my vars that i am watching aren't accesible. It's like 8 out of 10 breaks are outside my code. It's mostly the damn nt.dll that is always first on the call stack. oh well no big deal. i can always set up counting breaks inside the scope of my game.

Share this post


Link to post
Share on other sites
Ok. So looking down the call stack, can you see your code anywhere in the call stack?

If so, there isn't a problem. Just work your way out of the NT.dll until you hit your code. It may take a few steps.

There are sometimes some issues when you call into system code. The system doesn't maintain the stack in the way that MSVC expects it -- so you have to repeatedly step out until the call stack starts making sense.

At other times, you'll be in a system DLL that wasn't called by your code.

Is your code multi-threaded? You may want to look at the THREADs window to make sure. Maybe you are halting in the wrong thread.

...

If you are always halting in the system DLLs, that actually tells you something -- it means that the majority of the time, your code is spending time in the system DLLs. :)

Maybe you are allocationg/deallocating memory/resources too much, or maybe there is another explanation. It really depends on what your code is asking the system DLLs to do.

Share this post


Link to post
Share on other sites
Quote:

i heard that its an easy way to find out the slowest part of your code, just break 5 times, and whatever is in the call stack the most is probably a slow function, because most likely 90% of the time you should break in it etc.


That's a really, really terrible idea, actually. It's crude and inaccurate, even in the best-case scenario where your code is totally unoptimized (in which case its unsuitable for profiling anyway).

Look into getting yourself a profiler or learning how to insert timing/profiling code into your application.

Quote:

But it does show my exe using 99% cpu in task manager. And i get about 120 fps in the game.

This isn't really a problem. Windows is a not a cooperative multitasking environment. You're getting 99% of the CPU not because you're "stealing" it or anything, but because nobody else wants it but your game. If you want your game to reduce processor usage, have it Sleep() when it has nothing to do instead of spinning uselessly.

120FPS is probably not a huge performance issue either, depending on what you are drawing. But in any case, your "break every so often" methodology of profiling is rediculous and you should abandon it for more stable methods.

Quote:

What's the difference between /MT and /MD that I need to know about when making a game.

A quick search on the /MT and /MD compiler options from MSDN will tell you all about how they differ. Based on some of your posts, I'm not sure you have a complete understanding of what the differences are.

Share this post


Link to post
Share on other sites
Quote:
Original post by ViperG
I just hate it when i break that it mostly ends up in some dll that i don't care bout. Whenever that happens i have no symbols and my vars that i am watching aren't accesible.

I can't remember how VS2005 is set up by default, but that problem might be helped by going through Tools -> Options -> Debugging -> Symbols -> add http://msdl.microsoft.com/download/symbols and make sure it's enabled and caching somewhere sensible, if that's not there in the default setup. Then it should download the debugging symbols for system DLLs, so the call stack looks more correct.

Share this post


Link to post
Share on other sites
Quote:
Original post by jpetrie
Quote:

i heard that its an easy way to find out the slowest part of your code, just break 5 times, and whatever is in the call stack the most is probably a slow function, because most likely 90% of the time you should break in it etc.


That's a really, really terrible idea, actually. It's crude and inaccurate, even in the best-case scenario where your code is totally unoptimized (in which case its unsuitable for profiling anyway).


Yes, it is crude. But mathematically it is surprisingly accurate.

Know how monte carlo integration works? The rate at which a random sample based integration of a function converges to the intergrals value is not all that bad. This is the same technique -- monte carlo -- applied to profiling.

Quote:
Look into getting yourself a profiler or learning how to insert timing/profiling code into your application.


Instrumenting profiling changes the very thing you are looking at. It has it's uses, but it isn't always the ideal solution.

Inserting timing/profiling code into your application manually usually takes developer time to think about the problem. It is a great way to deal with "slowdowns" on the order of fractions of a second that can't be repeated (startup slowdowns, for example). It is also nice in that the data is captured and explicit.

Quote:
Quote:

But it does show my exe using 99% cpu in task manager. And i get about 120 fps in the game.

This isn't really a problem. Windows is a not a cooperative multitasking environment. You're getting 99% of the CPU not because you're "stealing" it or anything, but because nobody else wants it but your game. If you want your game to reduce processor usage, have it Sleep() when it has nothing to do instead of spinning uselessly.


99% CPU means that your program is running most of the time. If your program wasn't running most of the time, one would EXPECT to randomly break and get "not in the program".

It isn't a problem, but it is useful information.

Quote:
120FPS is probably not a huge performance issue either, depending on what you are drawing. But in any case, your "break every so often" methodology of profiling is rediculous and you should abandon it for more stable methods.


I find that it is easy to learn, easy to use, and it finds slowdowns faster than having to manually or automatically instrument your code and analyze the results.

It isn't a be-all end-all solution to profiling, but it actually works and actually lets you figure out what part of your code is slow.

It won't help you optimize the last 5% of your performance. But it will help you with the first 95% -- and it won't lead you astray into optimizing code that isn't taking any time in the first place!

[Edited by - NotAYakk on October 16, 2006 1:29:35 PM]

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

We are the game development community.

Whether you are an indie, hobbyist, AAA developer, or just trying to learn, GameDev.net is the place for you to learn, share, and connect with the games industry. Learn more About Us or sign up!

Sign me up!