I'm using web essentials to pre-compile all of my less files, of which there are many.
I have the bootstrap source (30+ less files) and my own 8 less files.
Merely saving a small change stops visual studio for a good 30 seconds. I'm obviously making a lot of changes, so I'm wasting a lot of time.
Is there any way of optimising this?
I'm aware there are equivalent plug-ins (work bench) but you have to pay for the LESS compiler. I'll do this as I suppose it's worth it, but only as a last resort.
In Visual Studio : Tools > Options...
Then : Web Essentials > LESS
and set Compile files on save to False so it won't compile every files each time you save a file.
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
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
I have recently been through the pain of converting an legacy WebSite project to a (C#)Web Application Project. During this time I also migrated the code from VSS control to Subversion on a dev server.
When debugging the application under VS2008 the project can literally take 4/5 minutes to completely load up. The majority of this time the Output Window states that it is loading symbols from Temp ASP.NET directory.
Figuring this may be an issue that it is under SVN control, I exported the project and began debugging without source control and this resolved the issue.
Can anyone suggest why this could be happening, ie. why under source control is it taking such a long time to debug?
Symbol loading shouldn't have anything to do with .svn. If moving your project solved the problem, I'd guess it's something to do with the difference between your actual copy and the exported one. Particularly, I'd say it would be to do with a file unlikely to be committed, like a ".user" file. The ".user" file probably has a lot of extra junk that VS is trying to load, and moving it means they got reset.
Check for any files missing (after a clean export...they'll have been re-created after you open the solution 1x) and you'll probably find the culprit.
You could try the TortoiseSVN client
The more plugins (Resharper etc) you have for VS the slower things tend to get.