Customers noticed an issue with large e-mails taking a significant amount of time to process when saving them. This issue was addressed in the Microsoft Dynamics CRM 4.0 release. I’d like thank CRM MVP Michael Höhne for investigating the buffer solution and Danny Feiler for identifying that four calls were being made to encode each string when one call would work.
Why are emails with large bodies in CRM taking too long to save or close?
Javascript does not have string builder object and so we normally resort to string concatenations which will lead to a lot of expensive allocation calls. When we encode our email body, we parse every single character for encoding and add this character encoded to the result string.
How do we overcome the shortage of StringBuilder in Javascript?
You can use javascript arrays to store the individual encoded characters and once the encoding operation is complete, you can use the Join method on the Array to join all these encoded characters into a single output encoded string and this is much much better in performance compared to the concatenation of each and every single encoded character.
Since large string allocations are done for every single encoded character, this operation will be very expensive unless we buffer the encoded characters into a smaller string and then concatenate this buffer to the final resulting string which will reduce the number of large string allocations by the number of characters in your buffer. If we buffer 500 characters in the buffer, we reduce the number of large string allocations by once every 500 characters instead of once every single encoded character.
Buffering technique was a tad bit better than the arrays technique atleast in the tests I performed.
How does this affect CRM?
All the forms in CRM application use the encoding operation and if you have large text like for example, the email body, the performance is affected when we have to encode this text.
How do I get this performance issue resolved?
Please wait for hotfix with KB number 948876 which resolves this issue.
How does hotfix 948876 resolve this performance issue?
This uses the buffering technique to resolve the string concatenation performance issue. We also need to only encode the characters when we are actually saving the form and not if we have to determine if the form data has changed or if we are closing the form. By removing these encoding routine calls in the close operation and dirty checks, and with the combination of the buffering technique the performance is significantly improved.
Thanks,