How do I speed up Nant Builds?

Question

Hello,

We have a number of Nant scripts which compile .NET code. These builds are taking 5 - 10 minutes to run, and I would like to find a way to speed them up.

Our Nant script looks something like

<target name="compile.XYZ" description="Compiles the source code">  
    <msbuild project="${src.dir}\XYZ.sln" verbosity="${build.verbosity}">
        <property name="Configuration" value="${build.config}" /> 
        <property name="OutputPath" value="${build.fullpath}/${prefix.xyz}" />
        <property name="ReferencePath" value="${assembly.dir}" />
    </msbuild>
</target>

They are all quite similar to this. I did investigate for nant but it looked a little out of date so I'm a bit hesitant to use it, although this could be quite handy as we do have multiple targets in our build.

Any help you could provide in improving the performance of these builds would be greatly appreciated!

Thanks :)

Answer 1

Assuming you have enough RAM, I'd buy a RAM Disk app (I use this one with good results).

Install your source on this drive, install Nant. Install 3rd party libraries there and other supporting infrastructure. It should yield at least 33% to 50% perf jump.

In addition, get an SSD and install the OS and .NET framework on it. Together you should be able to cut it down further.

Answer 2

The more projects you have in your solution the longer the build will take. Same with number of solutions.

Nothing really you can do about that. By the way, it isn't Nant thats slow here, its msbuild.

You could try some of the suggestions from Scott Hanselsman:

http://www.hanselman.com/blog/FasterBuildsWithMSBuildUsingParallelBuildsAndMulticoreCPUs.aspx

In effect this requires you to pass along "BuildInParallel="true"" to the task, although there are certain caveats.

This will allow projects within the same solution to be built in parallel, but I don't see a way to build multiple solutions in parallel.

For that, you could make a meta-solution (maintained only by hand, or autogenerated in nant before the build is done) where you add all the different projects to it.

Answer 3

Another way to go is to make MSBuild split up tasks based on its understanding of your code. You can use /m:x parameter to specify how many CPUs may be used. Or just /m to use all.

Some links for you to peruse:

• Hack: Parallel MSBuilds from within the Visual Studio IDE
• Faster Builds with MSBuild using Parallel Builds and Multicore CPUs

Answer 4

One of the things to look out for with any build system is to ensure its aware of all dependencies. In your case you are mixing build systems, which is fine but you have to make sure both Nant and MSBuild know your dependencies. If you have two interdependent solutions it may be beneficial to move those dependent projects to a solution of their own to ensure they are only being built once during a build cycle.

Make sure you're taking advantage of incremental compilation. If you don't trust incremental builds for release candidates use separate build targets for releases vs. testings and development builds. Also make sure you're using the appropriate compiler settings for the type of build being run.

Any solutions which do not have compile time dependencies on each other can be built in parallel. While MSBuild(3.5 and later) natively supports parallel builds on the same machine, Nant does not (its Java sibling, Ant does however). The one way to compensate for this is to create a master solution file that is only used by the build. This would allow MSBuild to parallelize independent projects. This slightly dated MSDN article list the benefits and drawbacks of different solution/project organization techniques. You can take this to the next level by setting up a build farm and building independent solutions on multiple machines. Most continuous integration servers support this.

Another thing to consider is whether your projects are following the DRY principle across multiple development projects. If two unrelated projects have classes with similar purposes they can be combined into a single class and move to a shared library. By removing code duplication you're not only decreasing maintenance costs you're also optimizing the build process at the same time. Finding duplication in unrelated projects is time consuming if your developers specialize on certain projects.