Join the DZone community and get the full member experience.Join For Free
Jumpstart your Angular applications with Indigo.Design, a unified platform for visual design, UX prototyping, code generation, and app development.
Starting a Profiling Session
Now open the Profiler tab and press the Start profiling button to enable profiling:
Then, press F5 to refresh the page and after the page finish to run press the Stop profiling and get the profiling report.
Reading the Profiling Report
When you have the report here are things that you need to pay attention while figuring out the information you got:
At the client there were a lot of calls to jQuery’s CLASS method. After figuring this out and seeing that the Exclusive execution time was very high I debugged the CLASS method and got the stack call to figure that there was a bug in an application function. Fixing the function helped to improve performance.
There are times that you will find that there are functions that got call in very similar numbers. This might indicate that they were called inside the same function. This is very inaccurate measurement but it might help sometimes.
- Inclusive time – this is the execution time of a method and all of its children. Here you’ll find the methods that executed for very long time. This measurement can help to figure out bottlenecks.
At the client we found out that Telerik’s RadGrid control and its inner LoadSod function are one of the bottlenecks in the application. I’m not saying here that the control has bad performance (on the contrary the control is fast) but only that in the application the control is one of the bottlenecks. I found a way to improve a little the control’s performance but the improvement was very negligible (50 milliseconds) so we dropped it.
- Exclusive time – this is the amount of time that is spent in the function itself. Here you can track very long running functions and then debug them to understand why the run for so long.
At the client we found a bug in one of the functions that was called with setTimeout very often and damaged the performance of the application.
Another way to use the report is the Call tree report that pack all the execution of functions in a tree view:
Here you can drill down the execution stack and figure out using the previous measurements how the application operate.
Opinions expressed by DZone contributors are their own.