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!

"Visit the Dynamics AX Community Page today!"

IL Compile and some things to understand for AX 2012

One thing I wanted to make sure and point out, with all this talk about Microsoft Dynamics AX 2012, Services, and Complex Data Contract concepts, is around the need for proper IL generation of Xpp / X++ code artifacts.

The image above is not technically correct for AX 2012, but it's a quick snag image, to capture the point of this post, in that there are some steps you have to take, in order for AX 2012 to make sure it can properly execute your service code.

I mentioned the use of SysOperations Framework, as well as Reliable Asynchronous execution mode for operating on more complex data contract concepts in the previous post. With that focus, and around the focus of any services that you deploy, AX must have in it's "Server/[AX AOS Service Name]/bin/XppIL" the correct and most recently compiled Xpp into IL code artifacts.

If, for example, you start running into strange issues, when using the SysOpeartions Framework, for Reliable Asynchronous execution, were messages appear in the batch job history for said job executions ending in error, make sure to follow these steps, so that you can be sure your instances XppIL is correctly up-to-date.

• 1. Click on the Incremental IL Compile button, within a Developer workspace
• 2. Restart your AOS

Doing this, ensures that the specific changes you might have made within an instance of AX and Xpp has correctly refreshed the XppIL artifacts for the given instance of AX, for the specific AOS(es).

I wanted to make sure and point this out for this morning as I'm sure quite a few of you might run into such issues. Doing this, will save you some unneeded research time, because most likely your issue is with a not so up to date XppIL Artifacts for a specific AOS.

That's all for now, but check back soon as a whole lot more to come! Till Next time!

"Visit the Dynamics AX Community Page today!"

Dynamics AX X++ Team looking for input

Last week, the Microsoft Dynamics AX, X++ Team posted on their blog that they are looking for community input. Being out last week, I did not pick up this, and just saw it today.

If you have seen this, and already left your thoughts great! However if not, please visit the following direct link.: More help needed from community: Do you rely on string truncation?

From the post.:
"Previously the X++ language allowed the LEFT and RIGHT keywords on definitions of string variables. That is no longer valid X++. However, we still allow specifying an explicit string length. The X++ language runtime implicitly does string truncation on assignment, both directly and when passing parameters. Consider the following example:

{
str 5 s;
s = ‘124567890";
}

The resulting string will only contain the first 5 characters, i.e. ‘12345'. Normally the user would not explicitly provide the length of the string in this way, but the behavior is exactly the same when using an extended type that has a particular length. One example is the SysGroup type, that is defined as having length 10 in the properties for the extended data type. If you run

{
SysGroup g = ‘1234567890ABCDEFGHIJ";
print g;
}

You will only get the first 10 characters printed. The remaining ones are lost to truncation."

Finally.:
"The question for you to answer is: Do you rely on these semantics in your code? Would your code run well if all string types were equal and unbound? Do we need to muddy the waters for IL by introducing the same behavior in IL?"

My answer to this is that the IL code should not be made to operate like the current Interpreter does. Don't make the generated MSIL code operate against the nature of how the MSIL code works in every other .Net langauge.

Truncation should only happen at the database level, and if true truncation is needed for some kind of validation, then it should be performed with strlen() and substr() calls.

That's my two cents, what's yours? Make sure to let the X++ team know!




"Visit the Dynamics AX Community Page today!"