Hi Wilhelm,
When NCrunch works over a grid, it will duplicate build and analysis tasks so that each node (+ local) will build and analyse the same project.
The alternative design considered was to have a single node (or local) build each project, then transfer the artifacts across the grid. This alternative design was rejected for the following reasons:
1. It was excessively complex, as presently grid nodes cannot connect to each other and the artifact transfer would need to be orchestrated by the local system. This was problematic when working in 'grid only mode'
2. There is little performance benefit from doing this, as the projects can still only be built as fast as a single machine can build them. This means that while one system is building the projects, the others are sitting idle waiting for the artifacts
3. Transferring build artifacts requires reliably identifying them. As build logic is essentially user code and is heavily customisable, there is no 100% reliable way to do this. Missing artifacts could result in strange problems downstream.
Considering the number of projects in your solution and your use of code contracts, I would speculate that the bulk of the processing being performed by NCrunch on your solution is being spent building projects. NCrunch's distributed processing doesn't give any performance benefits for building projects, as the MSBuild system itself is not distributed and the projects still need to be built in dependency order.
You might find that the only real benefit you receive from distributed processing is the ability to offload work from your local machine onto the azure node to keep your local resources free. If you later start adding tests to your solution with a high run time, distributed processing would become much more valuable.
Note that the custom protocol used for distributed processing was designed with consideration for slow network connections. The system will retain existing data on the remote node and will update it only with fresh changes that are made to the local solution. If you're concerned about the speed of your connection affecting the engine's performance, I recommend first experimenting before drawing any conclusions on whether or not to disable the local machine. Your azure node looks to be much better suited for background execution.
