X++: AxBuild.exe for Faster Full Compile of X++

[Blog bot]

Источник: http://blogs.msdn.com/b/x/archive/20...pile-of-x.aspx
==============

In this post we describe the new AxBuild.exe utility that you can use to greatly increase the speed of a compilation of all X++ source code. AxBuild became available in November 2013 as part of cumulative update 7 (cu7) for Microsoft Dynamics AX 2012 R2.

There are initial clarifications to understand about AxBuild:

• The legacy compilation options in the MorphX client remain available.
• AxBuild involves the compilation of X++ source code into AX p-code, but it does not involve the subsequent generation from p-code into .NET Framework CIL.
• AxBuild can compile all the X++ source code on the system, but its scope cannot be narrowed to compiling just a subset of classes and other elements.

Sometimes a compilation of all X++ source code is needed. Such occasions include:

• Setup of AX 2012 R2.
• Installation of upgrades and hotfixes.
• Migration from development to test, staging, and production environments.

1 Phases of any X++ Compile Process

In the earlier blog post, How the X++ Compiler works for AX2012 we gave a high level explanation of the processes that compile X++. Three major phases were described:

• Phase 1: Class declarations and method signatures.
• Phase 2: Metadata validation and method bodies.
• Phase 3: Recompilation of elements that had preliminary errors.

These phases apply to the compile process under AxBuild just as they apply to the compile process you initiate by clicking in the MorphX client menus.

2 Legacy Client Tier Compile of Full X++

Until today the X++ compilation and metadata validation processes were always executed on the client tier using one single thread. Figure 1 represents the X++ compilation process that runs on the client. The client requests metadata from the Application Object Server (AOS) tier. Metadata is needed for every element that must be compiled or validated. The metadata stored in SQL Server is de-serialized by the AOS into the internal representation of a TreeNode. Then the metadata is transferred over the network to the client. If the client and AOS are installed on the same computer (the “one box” configuration), a process-to-process communication over RPCs is used in place of a two tier network communication.

After the client received the metadata, the client compiles the X++ source code. The X++ source code is translated in AX p-code. The AX runtime understands the p-code and can execute it. The compile process also validates any references to other elements that are specified through properties. Information about any errors is written to a log. After each element is compiled, the client enriches its representation of the element with updated metadata and p-code. Next the client sends the enriched representation to the AOS. The AOS saves the updated element in the model store database.

Figure 1. Metadata transfer during compilation and validation process.

Agile development benefits from the client tier compile of X++, because the development cycles often require compilation of a narrow subset of all classes and forms etc. In the MorphX client the developer can compile individual elements such as one class. The developer can test the change, fix the code, recompile the one class, and retest. The compilations of individual classes complete in a second or two, so these agile development cycles are kept efficient.

Also, the compiler on the client tier is fully leveraged and integrated with productivity tools like Cross Reference, IntelliSense, and Visual Studio.

3 New AOS Tier Compile of Full X++

For a full X++ compile, the legacy client tier scenario is unpleasantly slow. Having the compilation run on the client is ironic for the following reasons:

• One irony is that the source code and the metadata are on the server computer, yet the compilation that needs the source and metadata is run on the client computer.
• The server computer is typically more powerful in terms of hardware.

In cu7 we are introducing AxBuild, an X++ compilation management utility that you run on the same server computer that hosts the AOS. AxBuild achieves its speed gains for the following major reasons:

• The client is excluded from the scenario. This eliminates the network communication from the AOS to the client and back. See Figure 2.
• AxBuild runs on a server computer that typically has more powerful hardware than the client computer has.
• AxBuild runs the compilation as a 64 bit process, instead of a 32 bit process as with MorphX. This allows more active memory to be addressed.
• AxBuild compiles subsets of AOT elements in parallel, whereas the client compilations process uses just a single thread.

Figure 2. Parallel compilation on the server tier.

Exclusion of the Client Tier: In the legacy full X++ compilation that runs on the MorphX client, the network transmission of information from the AOS to the client and back adds 28% to the wall clock duration of the compilation process. Even if the client is installed on the same computer with the AOS, transmissions through RPCs are needed.

Parallel Compilation: AxBuild starts multiple temporary AOS processes. These AOS worker processes run in parallel. AxBuild coordinates their compilation acitivities. AxBuild does the following:

• Assigns a subset of AOT elements for compilation compile to each temporary AOS.
• Collects the results from each temporary AOS, and writes the results to a log file.

AxBuild calculates the optimal number of temporary AOS workers as best it can, and it reports its calculation to its console. The calculation is based on the number of CPUs that the server computer has. However, you can fine tune and control the number of AOS workers by using the /workers= parameter. Factors you might consider include:

• Amount of active memory that the server computer has.
• CPU demands that other processes might make while the compilation runs.

4 Performance Gain

The performance gain depends on the available resources in the computer where the parallel compilation process is being executed, including number of CPU’s and memory available. However to put some numbers in perspective, we have taken some careful measurements.

4.1 Configuration

• MorphX client and AOS server installed on the same server computer.
• 4 Cores 3.7 Giga Hertz.
  • Hyper-Threading enabled, which logically doubles the CPU count.
• 32 Gigabytes of physical active memory.
• 6.0 Gigabits/s SATA Controller
• Windows Server 2012
• SQL Server 2012 SP1 Enterprise (no memory constraint)
• Virtual page caching disabled.
• Fresh AX 2012 R2, with cu7 installed.

4.2 Results of Performance Test

• AxBuild calculated 9 for AOS workers: 10 minutes and 40 seconds.
• MorphX client for comparison: 2 hours and 26 minutes.

5 Miscellaneous Details

• When you use the AOT of the MorphX client to import a .XPO file, the resulting X++ compile occurs only on the client tier.
• All generation of .NET Framework CIL occurs only on the client.
• The MorphX client is the Development Workspace window in ax32.exe.
• Even though the name of the AOS program ax32serv.exe contains ‘32’, it is a 64 bit program.
• AxBuild makes obsolete the AOS parameter -startupcmd=CompileAll that was described in KB 2844240, as in:
  ax32serv.exe -startupcmd=CompileAll
• For additional important information about AxBuild, see our formal Help topic on MSDN titled AxBuild.exe for Parallel Compile on AOS of X++ to p-code.

Marcos Calderon Macias
Gene Milener

November 2013

.




Источник: http://blogs.msdn.com/b/x/archive/20...pile-of-x.aspx