AX 2012 - Performance and IL - invokeStaticMethodIL
With the release of Microsoft Dynamics AX 2012, a huge focus has been around the move for X++ code to be compiled to IL, as well as creating C# code to achieve development needs, when possible.
Recently, I started talking about Performance in AX 2012, and how this goes beyond the database layer. It's still true, that the majority of performance is around the SQL Server, and specifically the disk I/O Sub-system speed.
However, with that said, there are some great improvements throughout the layers that make up AX 2012. Something recent that I highlighted was around Scale out of SSRS as well as Services.
Keeping with this theme, and to highlight some other area's of performance improvements, lets move towards the code side of things. To help set the stage, lets reference a Microsoft resource: Compile into .NET Framework CIL [AX 2012].
"The Compile into .NET Framework CIL task converts your compiled application code into Common Intermediate Language (CIL) code that can be consumed by the Microsoft .NET Framework."
With this, there are certain area's of AX that always compile down to IL / MSIL / CIL. All of those are in reference to the .Net Framework execution. This means, that the same C# code that actually executes, is compiled down to IL. The same now, takes place for some area's of X++. There are huge benefits in code execution when this is the case, and why this is such an important topic to understand from a performance point of view.
Keeping this in mind, there are sometimes when X++ code does not execute as CIL. Wouldn't it be neat, if there was a way to execute code as IL, X++ code that's not compiled down to IL? There is a way!
Enter: SysDictClass::invokeStaticMethodIL() "Runs the specified method and makes sure that the method is executed under X++ IL."
Now there are some remarks, that need to be understood from the above reference.: "This method demands the XppILExecutePermission class and asserts both the RunAsPermission class and the ExecutePermission class. The invocation will transition to X++ IL by using the RunAs function if it is running as interpreted. If it is already running as X++ IL, the method is invoked directly.
As there may be some overhead, this method should only be used on computationally-extensive methods.
This method will not transition to IL if the current TTS level is larger than zero (unless forced) because the transaction scope does not flow across IL boundaries."
With this in hand now, we have a way to help possibly boost performance, and execute static methods, and therefore area's of code that could benefit from running in the IL, or chunks of Business Logic that can be statically invoked or kicked off. This is a nice little gem of knowledge to keep handy, when your facing down performance issues, and really need to squeeze all the resource juice you can out of a process.
Well that's all for now, but check back soon as a whole lot more to come. Till next time!