views:

377

answers:

6

My project is developed in Visual Studio 08, in C#. It's a standalone desktop application, about 60k lines of code. Once upon a time I loved working on this software - now that the compliation time has grown to approx 2 minutes, it becomes a far less enjoyable experience...

I think that my lack of experience in C# may be a factor; I have developed everything under one namespace for example - would having a well structured codebase enable the compiler to recompile only the necessary parts of the code when changes are made? Or do I need to separate sections into separate projects/DLLs to force this to happen?

How much of a difference would upgrading to the latest quad-core processor make?

The other thought is, perhaps this is a typical thing for programmers to deal with - is a long compile time like this simply something that must be managed?

Thanks in advance.

+3  A: 

I'm surprised that 60k lines of code take 2 minutes to compile. I have an application that is 500,000 lines of code, and it only takes about a minute and a half. Make sure you are not doing full rebuilds each time, and make sure you are not cleaning the solution between builds. A normal build should perform an incremental build, only recompiling code that has changed since the last build (along with anything affected by that change.)

Perhaps some other factors might include heavy use of large resources (images?), broad-sweeping changes in the lowest level libraries (i.e. those used by everything else), etc. Generally speaking, on a relatively modern machine, compiling 60,000 lines of C# code should take less than a minute on average, unless you are rebuilding the entire solution.

jrista
Thanks for your response! "A normal build should perform an incremental build, only recompiling code that has changed since the last build (along with anything affected by that change.)" - this is what I thought would be happening - obviously not given your experience. So presumably there is something wrong that causes a full rebuild - whether configuration or structural. I will look further into the mechanism of the incremental build and hopefully nut it out
Pelirrojo
AFAIK, the C# compiler will only incrementally build at a per-project granularity. The compiler's performance would negate any possible benefit of tracking a incremental build cache. In other words, pressing "Build" shouldn't build projects that haven't changed, but will build projects that have.
280Z28
It depends on which code you're making changes to. If the changed code is part of an assembly that is a dependency for the rest of the project, it will trigger an (almost) full rebuild.
Thorarin
True, incremental build is per-project. But if the majority of projects haven't changed and are not affected by a change in a dependency, then they are skipped. The perception is that you get solution-wide incremental build, which usually makes for some pretty quick builds (a HELL of a lot faster than any C++ build I've ever encountered anyway...those things always ran for tens of minutes.)
jrista
I have been running an obfuscation process as a post-build event, which is totally responsible for the delay I've been observing. Thanks for your help!!
Pelirrojo
Ah! Thanks for letting us know the issue. Kind of an obscure one, but I'll have to file that one away in case I run into the same thing in the future.
jrista
+6  A: 

Things that increase compile time:

  • The number of projects in a solution makes more difference than the number of files in a particular project.
  • Custom build tasks can make a huge difference, especially if they are generating code or running post-build analysis (FxCop, StyleCop, Code Contracts).
  • Native code projects take longer to build.

A single project containing 60K lines of C# code with no special build features enabled should compile in seconds on any machine made in the past 5+ years.

280Z28
FxCop and StyleCop will slow things down dramatically, especially if you have lots of references to other assemblies.
Ants
You're absolutely correct - I have been running an obfuscation process as a post-build event, which is totally responsible for the delay I've been observing.Thanks for your help!!
Pelirrojo
+1  A: 

Splitting your project up into multiple projects will help. Only those projects that have changes (and projects that depend on it) will need recompilation.

A single namespace however, shouldn't affect compile time. However, if you do split up your project into multiple projects/assemblies, then a single namespace is definitely not a good idea.

Upgrading to a faster CPU will probably help, but you might find that faster I/O (better disks, RAID, etc will be more useful).

And yes, avoiding long compile times are one of the things developers need to take care of. When it comes to productivity, do whatever you can (better tools, bigger screens, faster machines, etc...)

Nader Shirazie
A: 

May I ask more basic questions? What hardware are you using? Is it at least dual core? Do you have at least 4G of memory? Is your hard disk at least 20 percent free? Is your hard disk big enough (more than 350G)? Is your hard disk at least 7200 RPM? When was the last time you did defrag? What OS are you using, is it at least Windows 7? I know I might be asking silly questions, but from my personal experience it is not common to wait 2 min for 60k lines of code and as a software guy, I say, it is always a hardware problem or an IT problem ((-:).

A: 

Write Better, Less Code! 60K?

Gordon Bell
A: 

There is this thread about hardware to improve compile time. Also this really excellent blog post from Scott Guthrie on looking at hard drive speed for performance.

Brad Patton