I have a project which reads in a text file (approx 2.6 GB in size), aggregates the data at some level and writes out a smaller file.
I've observed that if I run the program from Visual Studio in debug mode, it takes a lot of time to run (about 45 mins).
Instead, if I open a command prompt, move to the Debug folder in my Visual studio Projects folder and run the same exe, it completes in almost 10-15 mins.
I've also observed that the memory consumption is very high when running through Visual Studio.
I'm not stepping through the code, nor do I have any breakpoints in it. Why does Visual studio take so much longer to run the same executable compared to running it directly from cmd?
P.S.
I tried searching for this type of issue here, but most questions are about Visual Studio taking long while stepping through, or taking too long to start execution in debug mode.
I couldn't find anything about why the same executable takes much, much longer while running through Visual studio when everything else is the same.
The major cause of a probgram running much slower inside Visual Studio than outside is because of the Debug Heap which does a lot of error checking.
Try setting the environment variable _NO_DEBUG_HEAP to 1 in the project's settings (Debugger -> Environment) to disable this (see docs).
This should make it run a lot faster, though obviously you're not going to get as much error-checking - caveat emptor.
Think about it, when running inside the debugger, it (VS and debugger) will load the debugging environment, "instrument" and "analyze" the execution and will let you stop, set breakpoints, check and modify values, ...
When just running the DEBUG version, you will not load up all the debugger environment, you will just run the exe.
now, when you will compile your project in RELEASE, them will will be even faster.
Related
I'm working with simple c/c++ console projects in Visual Studio 2017.
After a build, if I run/debug it from within the IDE (Ctrl+F5 or F5), there's always a strange wait of tens of seconds before it actually runs (e.g. if I printf on the first line of my main(), it won't show until after the long "wait")
If there's no build after this first run, and I Ctrl+F5 or F5 again, it runs fast and normal. If then I change some source code and rebuild it, the strange wait appears again.
This slows down the dev iterations so much, and definitely feels wrong. Just wonder if any guru here can point me to a solution/workaround?
Thanks in advanceļ¼
OK, mystery resolved -- it's my Avira antivirus. Somehow after installing VS2017, it starts to scan each new exe I generated. After setting my dev folders as exceptions, things are a lot quicker. Finally.
Observed behaviour (everything here is on Windows 10):
I run Visual Studio (tried 13 and 15, both behave the same) logged into user A
After starting up, VS takes virtually no CPU time (<1%)
I log into user B, without signing out of A
VS imediately starts using A LOT of CPU time (~25% on my 4 cores with hyper threading)
I can go back and forth between A and B, and it goes back and forth between low and high CPU usage
This is all without any projects or files opened, though it also happens in that case.
I noticed this because I was originally investigating similar behaviour of a WPF application (after a user reported this issue).
While trying to isolate the problem, I found that even a completely new WPF project, with just a single empty window, behaves exactly the same (whether or not run through Visual Studio).
Through profiling and debugging I found that the app seems to spend a huge amount of time handling windows messages.
Specifically I found that it seems to be almost exclusively WM_PAINT messages (we are talking easily hundreds or thousands of messages per second - as many as the CPU can handle it seems).
No other programs I have running (chrome, skype, sublime text, ..) behaves this way.
Has anybody else seen this kind of behaviour?
And/or any ideas what could cause this, or how I could investigate this further?
Naturally, I cannot fix Visual Studio (unless the problem is with my setup somehow) but I hope there is something I can do about my WPF application.
As per Hans Passant's suggestion in the comments, I reported this problem to Microsoft here:
http://connect.microsoft.com/VisualStudio/feedback/details/2390593/wpf-apps-use-a-lot-of-cpu-time-when-logged-into-different-user
As it turns out this indeed seems to have been a bug in WPF, which is fixed in the current version of Windows 10 (probably specifically since the Anniversary Update (version 1607)).
Hence the solution: Make sure to update your OS.
I have a Visual Studio solution which I'm trying to build using the Incredibuild tool. Two of the projects in the solution work in tandem - the first project (we'll call it "Project A") builds an executable (foo.exe) which can parse a data file in the second ("Project B") to generate some header files.
Obviously there is a dependency on Project A defined in Project B. If I use Incredibuild's Rebuild Project option on Project B, it correctly builds Project A and foo.exe is successfully built. Project B has a custom build tool file which should cause foo.exe to be ran with a command-line argument to the file it's supposed to parse. However, trying to launch foo.exe in this way always returns an error:
CustomBuild:
Running Foo
'path to executable\foo.exe' is not recognized as an internal or
external command, operable program or batch file.
C:\Program Files
(x86)\MSBuild\Microsoft.Cpp\v4.0\V140\Microsoft.CppCommon.targets(171,5):
error MSB6006: "cmd.exe" exited with code 9009.
Interestingly, if I then use Incredibuild to build only Project B (i.e. using the Build Project option), everything is ok - it correctly picks foo.exe from the location it was built to on the previous, failed, build. This makes me think that the path, at least, must be ok.
Can anyone suggest why the executable cannot be ran as part of the rebuild? Is it a timing issue, e.g. Project B commences before foo.exe is known to the file system??
It all works under Visual Studio's regular (re)build. It's just the Incredibuild rebuild which fails. Note that I'm doing all of this through the Visual Studio IDE, not from a command line.
Edit: this is the freebie version of Incredibuild that I'm using (the one which comes with Visual Studio), so all of the build is on the local machine.
I contacted the Xoreax technical support about this in the end and they told me that this is a "rare but known issue that is related to one of our extra accelerating features".
Their first suggestion was writing an executable which simply sleeps "for a few milliseconds" and having that run as part of the custom build tool post-link. This did indeed solve the immediate problem, but the solution I'm building has numerous similar problems and adding this delay in everywhere quickly became tedious and didn't always work. It felt like a fudge anyhow.
So I asked if this behaviour can be toggled to off, and indeed it can. In Visual Studio the Incredibuild menu has an Agent Settings option, and from the invoked dialog's Visual Studio Builds|Advanced page it's a simple case of unchecking the Enhance throughput using out-of-order tasks spawning option.
Case closed.
There are options how to offload or intercept custom tools during your build process. Try to look onto "c:\program files (x86)\IncrediBuild\Samples"
I have a project in visual C 2010 that needs real-time timing in high priority to eliminate stuff like hard disk maintenance and stuff.
I ran the .exe file of my project using start "" /high & start "" /realtime.
(described here: https://superuser.com/questions/31802/starting-visual-studio-as-a-high-priority-process)
However, in the program I log the elapsed time and several other things, and running it this way stops the program updating the log files?
Note, for visual C, I found the .exe file in the debug folder with it's own separate set of log files.
you can use fflush() right after the logging statement so the data will be written to the disk.
see Flushing buffers in C
problem was, visual studio debug folder was write only. I was manipulating the .exe file in the debug, and that was why... take everything out into a new folder, and it should work!
I'm having an issue with VS 2010. It's running very slow and also crashes occasionally when compiling and packaging a xap file with the following error:
Xap packaging failed. Exception of type 'System.OutOfMemoryException' was thrown.
In the local Windows 7 temp directory \Users\usernamexxxx\AppData\Local\Temp
there are thousands of files, so I removed them and now VS is much faster.
Is anyone else having similar issues?
Yes, I have simmilar issue. when I clear My Temp Memory It works fine but after some time Temp directory is also showing some file.
and again the message comes "Out of Memory Exception".
It is an issue in Code. Your code is leaking memory. your code is not disposing object properly.
I haven't had that type of error message, but the thing that always seems to slow down VS 2010 for me is the .suo (Solution User Options) file. It basically keeps track of what files you have open, and your break points, but it is an always growing file. When it get's up to 5mb, it can take 20-30 seconds for VS to respond at times when adding a file, or deleting one from the solution.
I got tired very quickly of visual studio's slowness. My solution was to build everything on the command line using msbuild. I created a batch file which calls msbuild with my preferred options.
This option is actually really nice, because if you have a multi-core machine, you can pass the /m flag to msbuild, which will allow the build projects in parallel when possible (Visual Studio currently doesn't offer this functionality, but will in VS2012)
Calling msbuild is easy. For example:
C:\WINDOWS\Microsoft.NET\Framework\v4.0.30319\msbuild.exe MyApplication.sln /m
Then, if I want to debug, I just build first (on the command line), run the app, and attach the visual studio debugger manually.
I'm not familiar with this error in particular, but had an nasty issue back then with OutOfMemoryException during compile time for a big solution (more than 50 projects)
We used to circumvent it by using msbuild directly but debugging was a bit cumbersome
I checked on internet then and tried to extend the virtual memory that devenv.exe was using (by default it's 2GB).
Being on a 64bit Windows 7, the OS was already complying with the fact that an application could use more than 2GB.
Just had to fire up a command prompt and type :
cd\
cd "C:\Program Files (x86)\Microsoft Visual Studio 10.0"
copy Common7\IDE\devenv.exe Common7\IDE\_devenv.exe
VC\bin\editbin.exe /LARGEADDRESSAW Common7\IDE\devenv.exe
After a reboot, the compilation Exception was just a mere dream.
Note : I read afterward that Visual Studio 2010 was supposed to be Large Address Aware out of the box, so it shouldn't have "solved" my issue, but it did for me.