It has been a school day today (hence the Grange Hill image)
I have been reviewing some Javascript code to see if it can be optimized.
It can be tricky understanding someone elses code, particularly when the there are 12 javascript files loaded in the form and the code is jumping about everywhere, so it can take you time just to work out where to start and the code flow before you can start to think about speeding it up.
Another important fact, which is possibly more mental but I’m not sure what the form or code is doing which makes the code have an abstract feel to it. It shouldn’t matter what the form is doing, but for some reason it does, it must be the nosey parker in all of us. It’s easier to understand why the code is doing certain things when you understand what the form should do and why certain fields are important.
Waiting for all the scripts to load
The code was initially confusing is because the initial load script, called a bunch of other scripts and waited until they were all loaded. WHY?
To give you some background, the CRM release was CRM 2011 patch 12.
Microsoft tried to speed load times up by loading all the javascript files asynchronously (e.g. load them all at the same time). This caused a bunch of problems (what were fixed in rollup 15) because CRM loaded the scripts all the at the same time but some Javascript files called methods in the Javascript files scripts which were still loading. This would result in Javascript throwing an error because it couldn’t find the function.
So if you had scripts A, B, C.
Javascript file C could load first and start running, but in this script it calls a function from Javascript A, because javascript A is still loading this function call fails. Oops.
Amusingly someone explained this to me by saying do you remember the great javascript async cockup of patch 12.
ERM no, that passed me by, please explain was my answer
CRM MVP Scott Durow has written an excellent blog post on how to write some javascript which waits until all the other javascript files are loaded
So now I understood why the code was waiting for all the scripts to load. When you first come across methods for a first time, you wonder if this is a new best practice or something I should have been doing, why hadn’t I seen this code before?
In the form onload, it passes in a comma seperated list of scripts to load and the last one is the script and function loaded when all the scripts are loaded.
Aha I had my place to start.
OData code with no return value
In the code I found lots of OData calls which returned no value, puzzling I thought.
It was because the code was using OData to update CRM values but why it was doing it in the form load seemed rather odd.
I have never used OData to write values to CRM, why was this I wonder. Thinking about it, I guess I would usually update related entities or even the main entity with a plugin so it didn’t effect form performance.
here is an example of an odata update
http://rajeevpentyala.wordpress.com/2012/02/05/update-record-using-odata-and-jquery-in-crm-2011/
and another one
http://msdn.microsoft.com/en-us/library/gg309549.aspx
This code was particularly puzzling because it was updating values on the form onload? It turned out a bit of code re use from selecting an item in the grid, was also being triggered on a grid onload. So it was updating some values for every item in the grid.
This was an excellent place to start but I had to work out what I could remove without losing any functionality.
Fiddler Investigation
I had find the quick wins on performance, to weasel out the worst culprits for slow form load I used fiddler to see investigate the OData calls (which there were many)
Which OData calls took the longest
Find OData calls which were not filtered
Find OData calls which were retrieving the same data multiple times
I was also on the lookout for cases of inefficient coding, but most of the time was spent on odata calls, so that was my main focus.
Hosk's Dynamic Blog 