Through my career, performance have been a returning topic, and I have tried to share as much of my knowledge as possible. Today I would like to write about the .initValue() method, that is actually more costly than you think. Even if is empty.
I did a traceparsing to better understand the performance of inserting 10 sales order lines, that I feel is far below acceptable performance.
The Traceparser looked like this, and I was focusing on queries and statements that was unusual highly frequent for inserting 10 sales order lines. Specifically there where 548 calls towards a table named SysClientSessions.
SELECT {fields}
FROM SYSCLIENTSESSIONS T1
WHERE (SESSIONID=61852)
Why would inserting 10 salesorder lines result in 548 db calls on the session table? I looked at the callstack, and realized that the original source was from the .initValue() methods, that triggers a chain of events, and deep into the call stack I see that there is a call towards Global::isRunningOnBatch() to validate if my client is in a batch or in a GUI.
The issue is that SYSCLIENTSESSIONS not cached. It is set to “none”, meaning that any queries will always hit the DB.
But why are the .initValue() executed so many times?
It seems that for misc charges a table is used as a search paramater table as shown here, and in this process, it starts with executing .initvalue()
Code like this are stealing milliseconds from the execution, and this is just a very small example showcasing why deeper trace parsing in Dynamics 365 F&O are needed.
To achieve better performance Microsoft must start looking for unneeded high frequent queries and take them seriously. Even though this small extra query is only 0,83 ms per execution, the total amount is close to 0.5s as it is executed 548 times. In addition there will be latency and AOS processing time throw-out the callstack for each query.
I have encountered many similar situations, and I try to report them to Microsoft support. In most of the cases it returns back with “as designed” conclusion, and where support do not consider this as a bug. But if these minor details would get focus, the sum of such improvements would really speed up the Dynamics 365 F&O performance. Should I add them to the ideas site to die?
We in the community want Dynamics 365 to be the best solution ever, and fixing the minor things can really make a major change. I hope that Ostrich algorithm is not becoming an official Microsoft approach to minor issues, as what is actually wanted is perfection and not excuses.
This blogpost was written without any AI.
Kurt Hatlevik - Dynamics 365 Blog 
Sad to say, but perfecting D365FO doesn’t bring in new customers. And I believe that is Microsoft’s number one goal, together with making more money. Everything else is a lower priority. They put almost all of their effort into bringing new functionalities, which quite often are outside of D365FO as additional add-ins and tools, which they can then turn into money making machines. There are dozens of usability limitations in the system, already from AX versions, which Microsoft hasn’t bothered to fix. You know, the ones which partners are customed to fix/enhance in most of the implementation projects. I think it’s sad, very sad, but the American way of doing business is what it is.
LikeLiked by 1 person
Great catch and good point 🙂 Caching would make much sense for all small system methods that are widely used across the codebase and do not change return value over time.
LikeLike