I've been a little frustrated with how long it takes to build the main solution in my new job, having some 37 projects it seams to take an age to rebuild and get back to running and debugging after a change.
so my first problem is to enable the build time to be output so I can see how long it actually takes so I can prove my changes actually make a difference. so a quick google brings up VSCommands (how did I miss this tool before), while VSCommands can show a build summary the version containing this feature is only available for VS2010.
So back to google for another stab at it. this time I find this. perfect a macro that logs the time taken and puts it in the output window.. so how long does it take.. 00:03:45.0148701 while this doesn't seam too long it can be very annoying.
Moving on, after a few more minutes on google (google really is your friend) good old Scott Hanselman comes to my rescue once again. following advise from this blog I started doing some experiments, building the solution with 1 core using ms build took: 00:00:17.70 so what the hell is VS playing at maybe its because the build is running in the same process?? who knows.. Anyway when I switched this to auto detect the number of cores it brings the build time down to 00:00:11.96 now this figure I can live with. With just 30 minutes of searching I've managed to increase the build time 20 fold.
Unfortunately this doesn't really help the build time when you start debugging, but I think its useful non the less.
(update)
Strangely when using auto detect only 3 processes get spawned. so I tried specifying the number of cores to 4 and got it down to 00:00:11.32. the difference is so negligible that I've left it up to MSBuild to detect the number of cores.
(update 2)
I'm still not convinced by these figures.. need to look at this again..
No comments:
Post a Comment