Visual Studio's parallel compilation flag.

The most recent version of the Visual Studio F&O add-in enables parallel compilation of X++ code.

This is an exciting feature, and it is likely to speed up compilation time in many circumstances. In the next few paragraphs, I will walk you through how it works and when to use it (as well as when not to use it).

As you know, the Dynamics FnO application is split up into around 320 different packages that are almost all interdependent. At the root of the tree there is the Application Platform package that does not depend on anything else from an application code perspective. Everything depends on that package. If you use VS to render the full dependency graph you will see that it is quite overwhelming; To avoid drowning in such a complex situation, let’s examine a much simpler case.

When a compiler goes to work, it begins by creating a dependency graph – what depends on what - that defines the order in which compilation will be executed. In the illustration below, each node represents a package, and each edge represents a dependency. You will notice that package A does not depend on any other packages, whereas D depends on C, B and E.

Given the fact that A does not depend on any other packages it will be compiled first, leaving us with

With A out of the way, the compiler now has two components (B and C) that have no dependencies and can be compiled. A sequential compiler will pick one of the two (let’s say C), leaving us with:

Then move on to B, E and D before calling it a day.

So, a sequential compiler will just calculate a topological order and compile one after the other. A parallel compiler, on the other hand, will realize at the second step that there are two components (B and C) that are ready as they have no dependencies, and proceed to compile them at the same time. That’s all there is to it: with parallel compilation, the compiler will optimize its processes by taking care, at the same time, of all packages that are eligible for compilation (as their dependencies are satisfied) at any given moment.

Now, things may not be that simple: for example, the graph analysis can find loops in the graph. In that case there will be no ordering that satisfies the requirement that every package must have all its dependencies compiled before it can be compiled. Such a situation is therefore an error.

The biggest advantage of parallel compilation is of course in the way it optimizes, and typically speeds up, the compilation process, as the compiler can make good use of modern multi-core machines and process all the eligible packages in parallel, at the same time!

As usual, though, there is no such thing as a free lunch: parallel compilation comes with a few potential downsides, chief among them a potential RAM starvation as more processes will compete for system memory. We have a built-in failsafe that will gracefully degrade to strictly sequential compilation if that happens, and we prevent parallel compilation on systems with less than 16GB of RAM to avoid any problem. As RAM continues to get cheaper and more prevalent on consumer grade machines (I cannot believe I’m writing this from a laptop with 128GB of RAM), we expect parallel compilation to become more and more viable. This is even more true for cloud resources: there is no command line switch to enable parallel compilation so this feature cannot be used on build pipelines. We will for sure keep an eye on usage and feedback in its existing shape to understand if and how we should add a command line feature to enable parallel compilation on automated builds.