I build a C++ application that does some number crunching.
I'm running in Visual Studio 2008 PRO SP1, in release mode, Windows 7 64 bit.
If I run it inside the IDE, the application takes 4 minutes, if I run the same executable from windows explorer it takes 6 seconds!
I have no clue. I have checked that this does not depend on the processor and operating system. I don't think I have strange VS plugins that are doing something in the background.
Any hints?
Thank you in advance!
Marco
Presumably, the slow down is caused by the debugger being attached when you are starting the application in Visual Studio. This is the case even when you've built the program in "Release" mode.
To confirm that this is indeed the source of your problem, try running your application without the debugger, using the "Start Without Debugging" command or Ctrl+F5.
It's worth nothing that in C++ specifically, when you start without debugging, your program won't use the Windows debug heap. With the debugger attached, it will.
As Cody mentioned, one option is to simply not debug. But if you want to speed up your debugging sessions, here are a few things I've found can make a huge difference:
Remove debugging print statements that are no longer necessary. If you see your log filling up with text, that is likely slowing you down significantly.
Remove breakpoints (Ctrl+Shift+F5). A couple times I've noticed a huge drop in performance, and it turned out to be due to a breakpoint with a condition that was never met.
Related
There is a bug that I would like to fix that only occurs on Windows Server without a GUI running. I have set up a Windows Server 2019 machine on Google Compute Engine that reproduces the bug, and would like to debug it.
Ideally, I would like to use gdb, but seeing as the program was built with Visual Studio 2019, gdb can't read the debugging symbols.
I don't have a Windows machine, so using Visual Studio will be difficult. I could set up a VM, but if there's an in-terminal way to do this that would be preferred.
I did a pretty thorough Google search, but it didn't turn up anything. Is there really no Windows solution for debugging C++ code headlessly?
MS has 2 console debuggers called CDB and NTSD so you don't actually need Visual Studio GUI to do the debugging. In fact there are a lot of debugging environments in Windows from MS beside the usual Visual Studio. Just install them in your Windows Server and control them remotely from your terminal
You can also debug MSVC-compiled code with LLDB since the PDB format has been published long time ago and LLVM on Windows does support it. No idea about current LLDB on Linux though
And since you have the source code, sometimes the old-school printf debugger is the best way to analyze the issue
If you can get a Windows VM it'll be much better to do remote debugging. In fact almost all debuggers support that feature including GDB or LLDB, so even if you don't have the source code you can still run any Windows debugger and step through the instructions instead of high-level code lines from a remote machine
An alternative way is to take a memory dump and debug later. After getting the dump file, just drag it into your VS solution or any debugging tool like WinDbg and then select "Start Debugging". Now you can step through instructions/code lines and examine variables' values, or jump to an arbitrary function's stack frame just as if you're really running the malfunctioning app
There are many ways to dump a process' memory. You can set Windows to automatically save a dump file when your app crashes, or just capture memory snapshots manually during runtime. Comparing 2 snapshots is also useful for detecting leaked memory. For more information on how to do that read
Collecting User-Mode Dumps
Steps to Catch a Simple “Crash Dump” of a Crashing Process
There's also an easy way to take a dump of a live process using task manager (or any other similar tools)
I noticed that program execution in Visual debug mode is very slow (both release and debug version of the program). The performance drop impacts also non-Qt code which is just called in the GUI. In comparison to an old version based on MFC, the same non-Qt code runs > 10 times slower. I know that I can just start the program without debugger and everything is fine. However, the debugger is practical for reason. Does someone have a tip what causes the debugger problems?
Trying to launch the editor from Visual Studio 2013 Ultimate I get the following error in the title. VS says it's because it can't reach MSVSMON.EXE on a "remote computer", the weird thing is that I'm not trying to debug on a remote computer, but rather, on my own. My firewall is ZoneAlarm if that makes any difference.
Any help?
Edit: I've set all in and outbound communication to and from both unreal and visual studio in my firewall to "allowed", yet for some reason it still won't let me debug...
Edit 2: Disabling the firewall entirely does nothing at all.. The error persists
Edit 3: Uninstalling ZA altogether seems to fix the issue
Just a note, so far you've been chasing the wrong problem and have not yet gathered enough relevant facts. The dialog is very unhelpful, this does not have anything to do with a "remote computer".
Msvsmon.exe is used in this scenario because UE4Editor.exe is a 64-bit process. Visual Studio cannot use its built-in debugger, it is a 32-bit process. Debugging a 64-bit process with a 32-bit debugger is not possible. So it has a workaround, it uses the 64-bit remote debugger, C:\Program Files (x86)\Microsoft Visual Studio 12.0\Common7\IDE\Remote Debugger\x64\msvsmon.exe. Basically works the same has remote debugging on another machine, except it doesn't use the network to connect to the debugger.
So your firewall settings and the considerable amount of trouble-shooting info about remote debugging you can find on the web or MSDN just does not apply in your case at all. You've been chasing the wrong problem.
Having an issue with msvsmon.exe when debugging 64-bit code is quite unusual, never heard of anybody having trouble with it before. You want to do a basic smoke test to check if it is really a problem with msvsmon.exe or it is actually UE4Editor.exe that puts up a fight.
Create a little do-nothing C# console mode app, just Console.ReadLine() in the Main() method. Project + Properties, Build tab, untick the "Prefer 32-bit" option. This ensures it runs as a 64-bit process. Press F5. If all is well then it starts running and you'll see msvsmon.exe in the Task Manager, Processes tab.
If that does not work either then something is interfering with the process interop between Visual Studio and msvsmon.exe. Usually anti-malware related, disable that first. Next thing to try is to start killing processes one-by-one with Task Manager to find the evil-doer. If debugging the C# app works okay then you have a good reason to visit the UE4 forum to find help.
Update your question with what you've learned.
Uninstall Zone Alarm and everything will be OK.
When I run my exe outside of visual studio, with a release build, the graphics are very distorted. It works completely fine when I run it in debug mode, but I can't seem to figure out why it happens in release mode. It works fine if I start the application through visual studio though, which is the strange part. If you guys have any suggestion, I would really appreciate it. Thanks!
Expected Result (Debug Build):
http://i.stack.imgur.com/XH0cJ.png
Actual Result (Release Build):
http://i.stack.imgur.com/5lms0.png
(I don't have enough reputation to post picture)
There are two variables that are possibly not what you believe them to be. First, and less likely, is that there is code preprocessed differently than you believe. I don't believe that to be the case because if that were the whole problem, you'd see the same behavior in and out of VS. It may still be a factor, though. More likely, the culprit is in your configuration management; frequently, when you add projects or configurations, the configuration uses unexpected configurations from different projects. Check to see that your release configuration is using all release configuration versions of each project.
Other variables might be command line parameters and path differences, but I'm sure you've already checked that :)
Good luck.
Are you copying your geometry into the Vertex Buffer once at start-up or once every frame?
Check that your pointer to the geometry isn't pointing to something temporary; sometimes this will work ok in Debug mode (or Release mode when the debugger is attached) but will be optimized out when running as a standalone exe in release mode.
This is probably way too vague for any concrete answers, but this issue has been bothering me so I figured I'd give it a shot here:
Every time I hit F5 to run a project (and I'm talking something tiny 2 - 3 source files), first of all half the time it tells me that I need to rebuild the project even if the only change I made was add a breakpoint and then takes maybe ~20s to actually get the program running. This is a very basic command-line program and with gcc everything happens much, much faster. Any ideas?
PM
When using VS2010 on older operating systems (Like WinXP), then one should make sure to install latest UIA (Windows Automation) component MS KB971513. Failing to do this will cause VS2010 to perform poorly.
Also check ScottGu's Blog for other important hotfixes
The long waiting time before VS actually starts the application when hitting F5 occurs in VS 2008 as well. The simple solution to that is to delete the .suo file. I don't know if VS 2010 uses .suo files, but at least it's something you can try.
This might not be the case, but I remember VS used to act like this when I had lots of breakpoints.