Apr 25, 2013
Filed under: #daxmusings #bizapps

As I’m sure most of you are aware, compile times in Dynamics AX 2012 are a concern with more functionality being added. Especially on our build environments, which are (non-optimized) virtual machines, we are looking at around 3 hours for AX 2012 RTM/FPK and around 5 hours for R2. There have been discussions on the official Microsoft Dynamics AX Forums about this very topic, and there seem to be huge differences in experiences of compile times. After a lot of discussion with other people on the forums, and consequent chats with Microsoft people that are “in the know”, I think it’s pretty clear which areas one needs to focus on to optimize compile times.

1) The AX compiler was originally built when there was no talk about multi-core. So, as a result, you’ve probably noticed a compile only uses one thread. With today’s trend of more cores but at lower clock speeds, an “older” machine (CPU type) may possibly perform better than a new one, or a desktop machine may perform better than a high-end server. 2) The communication between AX and SQL is critical. The communication with the model store is critical (AOS gets the source code from the model store, compiles it, puts the binaries back in the model store). 3) The model store is in SQL so SQL has to perform optimally.

To this end, I set out to build one of our customer’s code bases (AX 2012 RTM CU3, no feature pack) on an “experimental” build machine. This code base has been taking an average compile time of 3 to 3.2 hours every time on our virtual AOS connected with physical SQL.

The new setup? A Dell Latitude E6520 laptop:

• Core i7-2760QM CPU @ 2.4GHz, 4 Cores, 8 Logical Processors
• 8 GB memory
• High performance SSD (Samsung 840 Pro), 256GB
• Windows Server 2012, SQL 2012, AX 2012 RTM CU4

Besides this hardware (2.4ghz clock speed - number of cores doesn’t matter, SSD to maximize SQL throughput), the key elements of our setup are putting the AOS and the SQL server both on this same machine, and disabling TCP/IP in the SQL server protocols so that it uses shared memory instead. This is the least overhead you can possibly get between the AOS and SQL.

The difference in compile time is staggering. I actually ran it multiple times because I thought I had done something wrong. However, since this is an automated build using TFS, I know the steps and code and everything else is EXACTLY the same by definition. So…. drumroll! (Note I didn’t list some extra steps being done in the automated build explicitly so that’s why it may not seem to add up…)

	Old Build Server	New Build Server
Remove old models	00:00:27	00:00:03
Start AOS	00:01:26	00:00:25
Synchronize (remove old artifacts from DB)	00:06:52	00:05:57
Import XPOs from TFS	00:13:17	00:03:55
Import VS Projects	00:00:29	00:00:11
Import Labels	00:00:22	00:00:08
Synchronize (with new data model)	00:05:42	00:01:55
X++ Compile	02:29:36	00:41:28
CIL Generation	00:13:41	00:05:29
Stop AOS	00:00:10	00:00:03
Export Built Model	00:00:42	00:00:12
Total Build Time	03:14:43	01:00:59

So yes, the compile time got down to 41 minutes! We’ve actually switched using this machine somewhat permanently for a few customers, we’ll be switching more. Now I need another machine for R2 compiles :-) I will post the compile times for R2 when I get to those.

Happy optimizing! :-)

 

There is no comment section here, but I would love to hear your thoughts! Get in touch!