First I would congratulate Microsoft with the release of Dynamics AX 2012. It looks very nice, and we get very good feedback from the marked on it. But this blog post is questioning the statement that AX 2012 is much faster than AX 2009. The reason why I raise this is because I often feel that the AX 2012 actually is slower than AX 2009 when it comes to opening, and using AX forms. I was then wondering if it could be related to the fact that I was using the Hyper-V image from Microsoft. I also wondered if it could be related to the hardware we used. To check out this, I decided to make some simple tests to compare AX 2009 to AX 2012 performance.
The first thing I did was to eliminate hardware restrictions. I get a new portable PC, with 8 CPU cores, 16 Gb RAM and 2 SSD disks. I then installed Windows Server 2008 R2 and MS SQL 2008 R2 with all updates from windows update. I then also installed AX 2012 locally from scratch, and applied the Cumulative 1 to the AX installation.
Then I decided to look into the form/List page “All customers”( CustTableListPage), because this form is functionally quite similar to AX 2009.
AX 2012 CustTableListPage form
AX 2009 CustTableListPage form
I then focused on opening this form, and time it. To get the best results as possible, I decided to open the form a few times before I started to time the opening of the form, to make sure that the AOS and SQL server had cached every thing in memory.
My findings was this:
|
Form name |
AX 2009 |
AX 2012 |
|
CustTableListPage |
1.4 seconds |
3,83 seconds (With Aero) 3,5 seconds (Without Aero) |
I have retried in several different environment and configurations, and the results are pretty much the same AX 2012 is SLOWER than AX 2009, when it comes to forms. And 3-4 seconds to open a form IS regarded as slow, because we often get the response requirement from customers.
I decided to see where AX 2012 is actually using time, and therefore started using the code profiler to time the AX 2012 with and without AERO
|
Form name : CustTableListPage |
Duration |
Method calls |
|
AX 2012 with Aero (client) |
3835150,0000 ms |
790 |
|
AX 2012 without Aero (client) |
3470196,0000 ms |
745 |
|
AX 2009 |
1413078,0000 ms |
253 |
We see that AERO enabled, the client actually needs to perform 45 additional method calls when opening this form on AX 2012, but the number of method calls compared to AX 2009 is more than doubled.
Here is the profile for when opening the form in AX 2012:
We see here that AX 2012 uses a lot of time in the SysSetupFormRun.init(), and that the SysSetupFormRun.loadUsersettings() is actually loaded 10 times. The reason for this is the fact boxes related to this form.
If we hide the fact boxes, we get a much better performance :
|
Form name |
AX 2012 with fact boxes hidden |
|
CustTableListPage |
2.0 seconds |
In the profiler we see
So the conclusion is, that to speed up the AX 2012, reduce the number of fact boxes that is loaded, because for each fact box added to a form, the SysSetupFormRun.loadUserSetting() is slowing your system down.
To hide fact boxes, the following can be done :
Also remark that AX 2009 is faster, because of fewer method calls. AX 2012 seams to redraw the screen for each loadUsersetting.
PS! It would be fun to compare AX 3.0 to AX 2012. Here I think the difference would be even larger.
Kurt Hatlevik - Dynamics 365 Blog 
Above regarding factboxes and preview panes definitely coincides with my experience. I quickly learnt to de-activate all those, but also to re-personalise the overview screens so that more of what I needed to see was on there straight-away and didnt require me to start digging into and the masses of underlying tables. The time that you initially lose in opening a fuller better-specified overview, you more than gain in not having to wait wait wait on each record drill-down. So frustrating!
Another major part of the reason for all the extra calls is the massive fragmentation of the data tables by MS. General ledger and general ledger transactions and dimensions are a particularly sad story. What was very few tables in Dx4 became more than a dozen in Dx12, and navigating through them was almost impossible to anyone but Microsoft. They seem to have allowed for a milllion “many-to-many” scenarios that do not exist and were not requested by customers. The point is that more separate tables means more calls, means more overhead, more time. I’m an accountant by training but I am quite technical so I was seconded to our implementation Dx4 team 13 years ago. I have therefore seen Dx 3>4>9>12. We are set to go 365 later this year (COVID19 willing!). What does the future hold for me on this version – more fragmentation, even slower ?
LikeLike
Hi, your explanation was good.is it possible to get back those Fact Boxes again?????????
LikeLike
Hi. yes, it is possible. There should be a “unhide” button.
LikeLike
Hi Hatlevik, I have a concern how ‘Hide and Unhide’ of fact boxes will impact performance. Since triggering of methods and its related queries are based on the invoking of record and it has nothing to do with vision.
Could you please elaborate here how hide of Fact box will impact performance?
LikeLike
Dimssy,
I have been testing AX2012 from CU1 to CU3 from a migrated AX 4.0 environment and currently testing CU4. As a company, If the speed is the same as the previous updates, then we will have no choice but to abandon the new release. The issue mainly is performance. You can’t expect to create a sales order and wait for the system to respond and print a confirmation and wait even longer for the report to pop up. Great product poor performance
LikeLike
As an AX developer, I find AX getting slower and slower. AX2012 is less predictable and much harder to work with.
LikeLike
Unfortunately the design of the AX2012 user interface is slower. If your function is to create and editing multiple sales or purchase orders or create master data – especially Items – everything takes longer – without considering performance.
LikeLike
Microsoft has released a “day in the life” benchmark of Microsoft Dynamics AX 2012 to measure the application’s performance and scalability characteristics, on a 48-core 256-gigabyte database server, supporting simulated 5,135 concurrent users.
It is a very good report, and I recommend to read it. Unfortunatly it don’t addresses the performance issues with fact-boxes.
But Microsoft has a disclaimer on that part : “These benchmark results were measured in a controlled lab environment, without other applications running. The response times reflect only server response time: they do not include the rendering time on the client.”
In otherwords : superfast AOS, and slow rich-client.
Check it out at here.
LikeLike
I guess that if it’s easily removable then ok, but how much of the “selling” eyecandy is just that; for sale purposes only. Which CustTableListPage would you prefer? the one spending 4 seconds loading or the version finishing in 2 seconds?
And I agree; Ax has been becoming slower by the version, thou everyone from a selling perspective seems to have a completely different opinion. Ax 3.0 don’t have the particular form you’ve tested, but my bet is that you’d find you assumptions true.
Speed is essential, anything else is counterproductive IMHO.
Good job by Kurt, mediocre by Microsoft.
LikeLike
Thanks for you comment.
Microsoft have actually made a setup option to disable all factboxes and preview panes for all users. So I guess they are prepared for theese questions. See under “system administration–>Setup–>System–>Client performance options”. I think I will recommend to disable factboxes by using this option to my customers when they upgrade to AX 2012. In my mind performance is all about how the end users are feeling the performance, and not how many server side transactions that can be executed in CLR compiled X++ code.
//kurt
LikeLike
Great Job Kurt – I also found the famous fat boxes slowed the performance considerably compared to AX2009 – AX2009 is actually much faster to use in many aspects – even bulk sales or purchase order maintenance – the design is easier to use. The fat boxes may sell the product well but can’t be implemented in all but critical places and limited fashion to ensure performance is ok for the user
LikeLike