here is the situation.
I am using visual studio 2005.
the solution contains lots of projects, 34 projects in all, and the start up projects depends on others.
then in linking part, it'll wait a long time before the real linking starts.
I am pretty sure it's because of too many projects depended, as when I use a solution with 10 of the 34 projects(keep other projects as headers&libs), it'll start instantly.
so any one has any idea that I can reduce the waiting time?
thx.
If 10 is fast and 34 is incredibly slow, you might try adding projects one-at-a-time to the 10-project solution until it gets slow. There may be one particular project that causes the slowness.
You could turn off "Whole Program Optimization", that should speed up the linking for you. Then you could use it in your final stages of release.
Enable the option in link-general-enable Incremental linking
Or
Unity Build
will useful for you
Related
I'm using premake5 here.
It generates my solution/project files, when this happens, VS2015 asks me if I want to reload the modified projects.
If I hit yes, this proceeds to lock up the IDE for a very long time.
Anywhere from 30 seconds to 1 minute I'd say.
Does anyone know of a way to work around this? This is super irritating.
It happens even for the most trivial of changes(modify one project, which only has 1 file in it).
I realize this is a VS problem, and not directly the fault of premake/cmake(or whatever build system you are using), but it totally sucks.
As you said, it's VS related :) But I think you have some problems with your installation : for small projects, reloading the whole solutions should be pretty fast : my personal projects take less than a second to reload (2 to 4 projects per solution, ~100 files per project)
Anyway in the usual course of development, re-generating your projects should not happen that often, except at the very beginning when you need to configure everything.
When you need to add a few files, just add them through Visual Studio : you won't have to run Premake again, and next time you run it, the files will be included by your script anyway. You can do the same with small configuration changes : update your project directly in VS, check that it works, and when it does, upadte the Premake script. You won't have to run Premake then.
I have a simple one-project solution in C++. From the IDE I click on Build Solution and it takes 40 seconds before anything happens. Then 17 seconds to actually do the compiling and linking. If I click Build Solution again, there is another 40 second delay. devenv.exe is busy doing something as it is using 13% of my total CPU during this time.
If I call msbuild directly, it starts immediately. And it doesn't recompile unless it is truly out of date. So it doesn't seem to be a problem with msbuild at all.
I have Googled and chased down lots of articles, but most of them talk about why msbuild is slow or failing, not why the IDE is slow to call msbuild. I've even got an external tool setup using msbuild and it starts immediately. BTW, that tool is based on this:
http://www.hanselman.com/blog/HackParallelMSBuildsFromWithinTheVisualStudioIDE.aspx
I have checked for missing files using the devenv.exe.config change and I do get items like:
devenv.exe Information: 0 :
Project 'C:\Users\...\XFPMon\XFPMon.vcxproj' not up to date because 2 build outputs were missing.
devenv.exe Information: 0 :
up to date is missing: 'C:\WINDOWS\TEMP\AEXAM\AEX7C29.TMP'
devenv.exe Information: 0 :
up to date is missing: 'C:\WINDOWS\TEMP\AEXAM\AEX7C28.TMP'
The change to devenv.exe.config was to insert these:
<system.diagnostics>
<switches>
<add name="CPS" value="4" />
</switches>
</system.diagnostics>
and then use DbgView to trace the output during the build. I cannot imagine why devenv.exe would think that TEMP files would be saved between builds.
I have even deleted the Debug and Release directories and compiled from scratch. Still the 40 second delay.
If I do a Rebuild Solution, another 40 second delay.
But if I do a Clean Solution, it runs instantly!
Does anybody have a clue as to what is causing the delay?
Thanks!
EDIT:
Further information. I have 8 cores, 12 GB RAM, and a 256 GB SSD, so this little machine has the raw horsepower.
When devenv.exe is in the 40 second delay period, it is drawing a total of 13% of the CPU. When the compilation starts, it drops to less than 1%. The memory usage changes very little. It starts at 458.2MB, rises to 459.9MB during the 40 second delay, and then jumps to 463.1MB immediately after the compilation (if any) finishes.
Well, I found the problem. An Addin was taking exponential time to process the .rc and .rc2 files. The Addin was put in many months ago and did not start showing this problem until the size of .rc file grew enough to cause the (poorly-designed) regex to run very slowly.
Worse, I wrote the Addin! And have been using it on several machines for about a year with no problems. Previous versions of the Addin were written in C++ using PCRE regular expressions and never had a problem (even after 5 years of use). But this was a rewrite using C# and .NET Regex, which apparently behaves differently.
I fixed the problem by rewriting the code to avoid the need for some of the backtracking. Simple enough to do, but irritating that it was necessary for C# Regex.
The key to discovering the problem was to start devenv.exe with the /resetaddin option. With this, a build starts immediately. Then it was just a matter of figuring out which addin. I just hadn't done this as I hadn't changed addins for months.
This problem showed up when the .rc file was as small as 12K. I have tested the new version on a 262K .rc file and it runs in 123 ms.
Sigh.
In my current project we have a very big solution with F#-project. I'm talking really big here . Its 70 F# projects (480 .fs files) and 4 C# projects.
As you probably guess this is starting to be a problem. First of all it takes forever to manage in Visual Studio. But then it also takes too long to build - last time I checked it took ca 3 minutes on my machine.
I know that there are (unsupported?) ways to organize F#-files in Folders in your projects but given the size of the solution I dread going through it and do that manually. Also we want to be pretty sure that it will improve the build time.
So, now my question - will merging into fewer projects decrease build time? Say that we get it down to 5-10 projects instead of 70 as of today.
If not - what can we do instead? How do you manage projects of this size?
I can't speak for large F# solutions but I've done this with large C# solutions, and seen build times drop massively. e.g. One solution had ~100 projects which we reduced to ~20 and build times dropped from > 10 minutes to < 5 minutes.
The gain came mainly from reducing dependency checking and the number of times files were copied from one project's build output folder to another.
If F# compilation is very slow it may be due to NGEN not having run after recent .net framework updates. See these two stackoverflow questions: f# compiling too slow and F# is running very slow since last round of Windows updates for more information
Tried SSD & RAM drives doesn't do much.
Dependencies between projects might prevent you from gaining anything from increasing the number of concurrent build.
I'm a bit surprised you have 480 .fs files in 70 projects... that amounts to about 6-7 files per project which isn't much. It might be worth looking over that anyway even if it's not for performance reason - one can have (will?) design issues either way. But build time seems to be consistent with the number of files (or LOCs) per project so you may not squeeze as much as you'd want there.
I personally lost the habit of cleaning and rebuilding every time for that reason.
Edit: Found a related note in Expert F# which I thought was worth mentionning:
.NET assemblies often contain a large amount of code. For example, a single assembly may contain as
many as 50 or 100 F# source code files. Having many small assemblies may seem tempting, such as to improve
compilation times during development, but can lead to difficulties when you’re managing updates and can be
confusing to end users. Large assemblies are easier to version: you have to update only one component, and you
can package multiple updates into a single new version of the DLL
In the last year I've worked on two relatively large .NET projects and both of them have ended up with project/code generation strangeness that I just haven't figured out how to fix..
The first project generates some bad code for forms that causes the VB.Net build to fail. I actually had to make a search/replace macro that fixes the 5 problems by adding a Global. to the beginning of a few references.
I chalked that up to a random act of unkindness against me and went on my way since the macro takes about 2 seconds to run...
So now 6 months later and new project is cranking along and I get a similar-ish problem. I have a bunch of form controls that store state in a settings file using the built in capabilities of .Net. I had about 20 controls that were configured automatically this way. Works great until today when for reasons I don't understand in the designer.vb file gets corrupted. At least one other person on the planet has had this problem here:
http://social.msdn.microsoft.com/Forums/en-US/winformsdesigner/thread/9bd20b56-7264-4a1f-a379-ad66b372ddd3
but the proposed solution didn't change the behavior.
So now I've had two projects (larger ones) that have project file issues that I can't resolve (I've had several smaller projects that are just fine).
What tools are available to fix projects, migrate projects, lint projects ... anything to recover projects to a reasonable state? Any successful recovery procedures beyond a roll-back/merge?
i had a corrupted reference issue linked to my use of mercurial and VS getting lost in file save time... if this may help...
If you open it in notepad and its corrupted - then its probably corrupted and the only way to restore it would be to go to a backup.
--> go to backup
-->click your project name
-->and then find your fire thats are corrupt
Our issue is as follows:
solution takes a while to start up when running
after hitting run and while monitoring the Output window, constant work done is loading project related files from .net temp dir
this really takes a while
this is a Web Forms app with quite a large set of UI controls/pages and about 250 DLL/component dependencies
references are added as DLL refs and not proj refs
Given the information above, what would be some of the suggestions to speed up solution startup at run times?
Frankly, there may not be a whole lot you can do. But be sure to disable antivirus scanning of the project, as scanning each file as it loads will slow the machine to a crawl.
There are a few other tips floating around, but I'm hoping performance will be improved via an update of some sort.
Lots of links and things to try are here:
http://www.experts-exchange.com/blogs/TheLearnedOne/B_4684-Visual-Studio-NET-2010-Performance.html