Compile times and drive speeds

P

pilks

Well-Known Member
Joined
Oct 9, 2009
Messages
129
Reaction score
0
I currently have 6 X 500gb drives in RAID 0. Silverlight applications still takes ages to compile.
I have tried formating many a time(usually once a month) to speed up the compile times. Adding the Visual Studio folder to the excluded list in my AV works but still too slow

Now I have been wondering, will 2 x SSD in RAID 0 make my code compile quicker ? Or should I look at a faster processor or what else do i need to do to make my Code compile quicker.

I develop in C# or VB


My PC specs are

I7 930
8gb DDR3 RAM
 
Why is compile time so important to you, if it is slow, you should probably be making coffee instead. Compiling is generally done by the CPU and hense disk will not effect this too much unless it s writing a ton to the disk itself. SSD's are faster at reads and slower at writes so you probably would not get much of a benefit. Your best advice is probably just a bit a patience.
 
A while back I had a machine with a 7,200rpm drive. Got upgraded to a 10,000rpm and definitely saw an improvement. Apparently SSDs aren't too great at improving compile time and using a RAM disk provides the best performance increase.

- http://weblogs.asp.net/scottgu/archive/2007/11/01/tip-trick-hard-drive-speed-and-visual-studio-performance.aspx bit old but still applicable
- http://jeffreypalermo.com/blog/speeding-up-the-build-ndash-ditch-the-ssd-and-go-for-the-ram-drive/

Can't say that I've tried the RAM disk solution, would have to figure out how best to get the code onto the disk but not lose it if the power goes down :)
 
I've never had issues with compile time, how long are we talking about?
 
The easiest way is to look at the output window and see if MSBuild will tell you anything.

All .net code gets built with MSBuild and if you are using VS2010 C++ code will also be built using MSBuild.

To understand why it takes long, you need to understand MSBuild and what it is doing. I won't go into that but there are a few ways to get build working faster. Compiling is a processor intensive task so adding a faster HDD or SSD may not solve your issue. What your want to do is maybe get a processor with more cores available and where possible make use of parallel builds.

What you can do to try and get more information about your build is to get Visual Studio to put out verbose logging in the output window. That will tell you everything that is happening while you are builing and would make it easier to identify areas that can improve - if any.

What you also need to take into consideration is the amount of projects in your solution that need to be built. The more projects, the longer it will take. If you make use of automatic proxy generation then that will also lengthen the time it takes to build and you can't really cut down on that - maybe look at how and when you generate your proxies.

With the information you provided, nobody will be able to help you out with why its taking long...

As a matter of interest, howmany projects do you have in your solution? How long does it take to build?

Edit: With Silverlight you have to take the following into consideration:

It will always take longer since all the output of you SL app gets zipped up by the System.Packaging API and the copied to the correct folder of your website. This always takes an extra few seconds where VS just hangs around.
 
Last edited:
MilieSpoor said:
Compiling is a processor intensive task so adding a faster HDD or SSD may not solve your issue.
Click to expand...

Multi-core CPUs on machines have gotten fast enough over the past few years that in most common application scenarios you don't usually end up blocking on available processor capacity in your machine.

What you are much more likely to block on is the Seek and I/O speed capacity with which your computer accesses your hard drive. If you are using an application that needs to read/write a lot of files, it is not atypical for your CPU processor utilization to be really low - since the application might be spending most of its time just waiting for the disk operations to complete.

When you are doing development with Visual Studio you end up reading/writing a lot of files, and spend a large amount of time doing disk I/O activity. Large projects and solutions might have hundreds (or thousands) of source files (including images, css, pages, user controls, etc). When you open a project Visual Studio needs to read and parse all source files in it so as to provide intellisense. When you are enlisted in source control and check out a file you are updating files and timestamps on disk. When you do a compilation of a solution, Visual Studio will check for updated assemblies from multiple disk path locations, write out multiple new assemblies to disk when the compilation is done, as well as persist .pdb debugger symbol files on disk with them (all as separate file save operations). When you attach a debugger to a process (the default behavior when you press F5 to run an application), Visual Studio then needs to search and load the debugger symbols of all assemblies and DLLs for the application so as to setup breakpoints.
Click to expand...

I think Scott Guthrie kind of knows what he's talking about.
 
stevenv said:
I think Scott Guthrie kind of knows what he's talking about.
Click to expand...
Will he notice the diffirence when using a SSD when building a solution with 1 or 2 project? Most probably not really. Will be see a diffirence when build a solution with 30 projects in - yes he will...

At the end of the day, the build process consist out of various tasks and functions that needs to be done. Some take time others don't. On small scale projects, as is most probably is the case with him, you won't really notice a diffirence where you would say you wont 10 - 20 second when going SSD.
 
How big is the codebase? If its fairly big, and you have other developers that might benefit, get Xoreax IncrediBuild. Its very expensive, but very good. It distributes the entire compilation and linking process to any connected computer (license needed for each), depending on how used each PC is. Ie, you have it installed on your PC, another server and your colleagues machine. You want to build, you can use all of your own CPU cores, all of the server CPU cores (provided it doesnt need them), and any of your colleagues CPU cores/time that isnt in use. Can really speed things up.

I think its like $500 per license and you need a license per machine. Sometimes worth it though, I wish we had it at work because my work laptop is a 2.5Ghz dual core, with a 5400 RPM drive (I presume) so its dog slow.
 
So many questions, so few answers :)

If he's complaining about a small code base taking a long time to compile then there are some other serious problems. But on the other hand, "a long time" is relative: if it takes 10 seconds instead of 1 second, maybe he's being unrealistic. On the other hand, if we're talking about a "large" codebase, steps can be taken to improve performance and I think these will involve physical disk I/O as opposed to CPU cycles.

I use the term "large" loosely, 100 > 10 but also 1,000,000 > 10 :p
 
You must log in or register to reply here.
Back
Top
Sign up to the MyBroadband newsletter
X