Have you ever experienced a slow linking process in a C++ project compile (I'm using VS2013)? I get linking process taking 15 minutes after a 5 minutes Build. A Rebuild or Visual Studio restart does not fix the issue.
Task manager shows mspdbsrv.exe taking a full core (25% on a 4-core), and pdb file creation is very slow, Kb after Kb it reaches 50 Mb.
Additional info:
the same project on another computer build and link in acceptable time.
antivirus is disabled
I've tried changing the pdb file creation location: no success
I've set the linker output Verbose, but it stops at one debug row and then wait all the time there.
VS2013 is updated to SP4
Hard disk activity led on my laptop is mostly turned off, so there's no full activity on the disk.
I'm running Windows 7 Pro.
VS2013 is run with administrator rights
Thank you.
Fixed changing "Debug Information Format" from /ZI (Edit and Continue feature) to /Zi. I still have no clue why this cause a slow linking only on a specific computer and not for the others. Hope this could help people coming here for the same issue.
Is it using Link-Time Code Generation? On VS2010 that step was single threaded so it takes much longer than the apparent compile step. On later versions this step was improved to be multithreaded, according to blog posts. It also mentioned that PDB access is a bottleneck. So, maybe you have an old mspdbsrv.exe on that system? Look at the version info on the file, compared across machines. There might also be some option to control its locking and multi-use behavior, hidden away someplace.
Related
Trying to profile my command line application in VS 2017 on a W10 machine with April 2018 Update, VS fails to create the report.
The UI says Microsoft Visual Studio was unable to create a diagnostics report. Check Output window for errors.
The Output window says
Profiling of 'Program' started.
Program has exited.
Profiling of 'Program' stopped.
Diagnostics session stopped with errors.
Merging of ETL files has failed (0x80070070) (Flags: 0x0000011f).
Previous search gives little answers as to why, but the problem seems related to Windows' event logging service. Comments on this similar question suggest it's related to disk occupation, but with no source. My SSD is indeed almost full, but with 6 GB of free space.
I resolved the issue, the multiple times it happened, by restarting windows and then start the profiling as first thing as the OS is ready. On a fresh start it works, but going further with changes and profiling it eventually appears again.
If someone knows a long-term solution feel free to add.
Code 0x80070070 "There is not enough space on the disk." Your disk was full, or became full during a build or other operation as temporary files were created.
I was using RAD 10.1 (Berlin) with no problem until now... Last month I applied Windows Creator Update and was occupied by other businesses... Now, each time I start the IDE, the loading progresses quickly up to "All design time packages loaded". At this time RAD studio sits on its splash window and consumes ~25% CPU. It takes at least 10 minutes before the IDE appears...
I've installed RAD 10.2 (Tokyo) and all provided patches, hoping for a fix... But the problem remains the same.
I can't go back to previous version of Windows 10 (more than 10 days after install).
I've already searched for an answer and Matthias E suggested that it was linked to https://quality.embarcadero.com/browse/RSP-17972.
But, in my case, the (very) long period stands only for IDE loading even when there is no project to (auto)load. I'm not talking about the time-period to load the project or to start project execution or even to start the application execution. Once the IDE has been loaded (after ~20'), everything (editing, compilation, building, debugging, execution) is working quickly...
I have become accustomed to never close the IDE once opened but this is particularly disturbing.
Could you help me ?
--- Edited ---
For those who cannot access the link above, here is the content :
Details
Type: Bug Bug
Status: Open Open
Priority: Major Major
Resolution: Unresolved
Affects Version/s: 10.2 Tokyo, 10.1 Berlin Update 2
Fix Version/s: None
Component/s: Debugger, IDE (Development Environment), Libraries/Frameworks
Labels: None
Platform: Windows 10
Language Version: English
Edition: Professional
InternalID: RS-83785
InternalStatus: Open
Description
The debugger goes haywire for everyone in our organization with Creators and Tokyo/Berlin. Reverting to Windows Anniversary brings back the sanity.
Debugger problems with Tokyo/Berlin and Creators:
App takes a long time to load with modules loading and unloading and re-loading many times
IDE freezes
Memory consumption of bds.exe explodes, sometimes (> 3GB)
I will attached before and after screenshots showing how modules load and unload and re-load with Windows 10 Creators.
I presume these problems have the same root cause(s) than those in https://forums.embarcadero.com/thread.jspa?messageID=884382*
--- ---
Thanks to Lieven Keersmaekers's suggestion to use procmon, I was able to find the cause of the problem. RAD studio was heavily trying to access an enormous (128 GB) zip backup file (see : qed-electronic.com/Download/170808-ProcMonTrace.jpg ). I've simply moved the backup file to another location and RAD studio now starts as before. I have no idea why RAD wanted so much to access this file : none of my project files were located in this zip. The Windows Creator Update was apparently not guilty...
bds.exe must be launch with only one CPU !
CPU Affinity CPU=0
Thx to Javorszky
https://community.embarcadero.com/forum/installation-issues/1408-running-from-ide-freezes-windows-10#4173
To run quickly without entring TaskManager and change Setting CPUAffinity,
just create a batch file on the desktop:
cd "C:\Program Files (x86)\Embarcadero\Studio\19.0\bin\"
start /affinity 1 bds.exe
Why ?
"The reason for this is that most applications you run these days have been designed with multi-core processors in mind and will work with the operating system to distribute their operations as evenly as possible across all the available cores. "
see : https://www.techrepublic.com/blog/windows-and-office/change-the-processor-affinity-setting-in-windows-7-to-gain-a-performance-edge/
I have installed visual studio 2013 Ultimate on Windows 8 enterprise edition.
When I start debugging an mvc project (which pretty empty) : it takes 27 seconds to start the debugging. I assume it's because IIS express 8 is loading symbols and hangs somewhere.
I have tried an empty mvc project and it starts in 10 seconds : which is very unacceptable.
I have tried :
- deleting all breakpoints
- enabling just my code
- unchecking symbols downloading from microsoft servers and downloading them on a local folder on the computer
- disabling intellitrace (was already disabled when i went to see)
- disabling just-in-time (was already disabled when i went to see)
- unplugging the ethernet cable (yes, i am pretty desperate)
- no antivirus is turned on
The first request (when i launch debugging) always take 27 seconds according to glimpse. The controller run under 1 second which is "acceptable". All the next requests are fine.
But I can't work with the 27 seconds each time I launch debugging.
Can someone help me ? I do not know what to do next.
My computer is a dual core 3Ghz with 4 Go of Ram and a 7200 rpm hd. I don't think it's hardware related.
Thank you very much.
UPDATE :
As soon as I start to use NLog in the code, it takes 30 sec to launch the debug mode.
If I comment all the place where I log something, It takes 10 sec. Sometimes less.
How much time you guys take to launch the debug mode ?
It's quit possible you are referencing dead or slow symbol path. For example, you're at home but accessing a symbol path on company's server. Check it under Tools -> Options -> Debug -> Symbol. If it's ok, check your system as follows.
Make sure there is no other process that runs out of your hardware resources.
First check if CPU usage is too high after staring debugging. If CPU usage is too high, use Process Explorer to check what activities VS Is performing. If they are in an extension thread, disable that extension. If they are in VS own thread, it's most likely a VS bug you can report to MS.
Check if memory usage is too high. If VS memory usage is too high, given that you just start simple debugging, it's a VS bug.
If both CPU and memory are ok, it's probably related to IO operation. Use Process Monitor to check which files are being accessed, especially files on remote machine.
This is how I troubleshoot the same problem on my machine. Hope it help you.
I am aware that there are a couple of questions that look similar to mine, e.g. here, here, here or here. Yet none of these really answer my question. Here it goes.
I am building a modified version of a Chromium browser in VS2008 (mostly written in C++). It has 500 projects in one solution with plenty of dependencies between them. There are generally two problems:
Whenever I start debugging (press F5 or green Play button) for the first time in a session the VS freezes and it takes a couple of minutes before it recovers and actually starts debugging. Note that I have disabled building before running, because whenever I want to build my project I use F7 explicitly. I do not understand why it takes so long to "just" start a compiled binary. Probably VS is checking all the deps and making sure everything up-to-date despite my request not to build a solution before running. Is the a way speed this one up?
Every time I perform a build it takes about 5-7 minutes even if I have only changed one instruction in one file. Most of the time is consumed by the linking process, since most projects generate static libs that are then linked into one huge dll. Apparently incremental linking only works in about 10% of the cases and still takes considerably long. What can I do to speed it up?
Here is some info about my software and hardware:
MacBook Pro (Mid-2010)
8 GB RAM
dual-core Intel i7 CPU with HT (which makes it look like 4-core in Task Manager)
500GB Serial ATA; 5400 rpm (Hitachi HTS725050A9A362)
Windows 7 Professional 64-bit
Visual Assist X (with disabled code coloring)
Here are some things that I have noticed:
Linking only uses one core
When running solution for the second time in one session it is much quicker (under 2-3 seconds)
while looking up information on VS linker I came across this page:
http://msdn.microsoft.com/en-us/library/whs4y2dc%28v=vs.80%29.aspx
Also take a look the two additional topics on that page:
Faster Builds and Smaller Header Files
Excluding Files When Dependency Checking
I have switched to the component build mode for Chromium project, which reduced the number of files that need to be linked. Component build mode creates a set of smaller DLLs rather than a set of static libraries that are then linked into huge chrome.dll. Also I am using incremental linking a lot, which makes linking even faster. Finally linking for the second and subsequent times gets faster since necessary files are already cached in the memory and disk access is unnecessary. Thus when working incrementally and linking often, I get to as low as 15 seconds for linking of webkit.dll which is where I mostly change the code.
As for the execution it has same behavior as linking - it runs slow only for the first time and with every subsequent run it gets faster and faster until it takes less than 3-5 seconds to start the browser and load all symbols. Windows is caching files that are accessed most often into the memory.
Not sure what has happened on my dev machine but I can barely use visual studio 2010 these days. I have a copy of professional edition installed on a win7 pro x64 build running on top of a i5 M430 and 6 gigs of ram.
With only VS2010 open i've seen the process leak away to 600,000k+.
The editor is extremely slow. Every character I type sends the gui into "Not Responding" for 5 seconds and starting/stopping the debugger is a ~30 second operation.
I've done a repair install. No change.
I've removed productivity power tools and installed the perfwatson extension.
When I installed perfwatson the GUI sped up a bit while opening/loading a project. But the text editor still has an awful delay.
What else can I do? Harware rendering is off in my environment options.
an example of the slowness (literally): typing Height="1024" takes about 30 seconds to display in the text editor and do its update flash to go out of not responding. The word "Height=" takes 5 seconds to show. The intellesense and blank " " takes another 5 seconds. Each digit pops in every five seconds after that.
Needless to say even trying to edit existing work is a frustrating experience.
edit: rolled back one version on video driver. No noticeable changes after reboot.
edit: did some winforms projects today. No slow issues with this project type. Must be something with just wpf/sl projects.
edit 8/18/11: Took troublesome project to the production server. VS2010 editor works great there. Very snappy and responsive. Not at all slow. So it's not something inside my project. It's something in my machine. But a full out OS rebuild is something I can't just do now. Probably will start a bounty soon.
Delete the .sdf and .sou that have the same base file name as your solution file.
If your solution file is
c:\MyProject\project.sln
You should delete
c:\MyProject\project.sdf
c:\MyProject\project.sou
This solves 98% of the problems of slow VS.
These files contain intermediate information that is not important for the functionality of the solution and as time goes by they swell up and become bloated and fragmented. VS relies on these files for and if dealing with them is slow, everything is slow.
I know this is an old post but I have just had an issue where my visual studio project has been working fine for about 2 1/2 years and suddenly every time I clicked run I had to wait about 3 minutes and the same when clicking stop. I tried the old windows reboot but to no avail.
I found a post about deleting the projects .suo file (it was only 4MB).
I deleted the .suo file and everything is completely back to normal. I guess the file had corrupted or something.
Having a large number of breakpoints or a large number of files open can cause serious performance problems, but it sounds like your problems are worse than that...
A bios update and a intel chipset update on my machine solved nearly all my performance issues.
The slowness started to creep out into the OS and I was pegging the cpu at idle. I've got 4 cores and 8gb ram. It shouldn't do that. Now its happy at 8% load at idle.
Thanks to those that tried to help.
had the same problem. not sure what causes this ridiculous performance nightmare, but eventually i had to re-install windows. This same issue was posted on Microsoft forums but the best answer was to re-install VS or windows.