Join the DZone community and get the full member experience.Join For Free
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:
count – when the count of function calls is very big (for example
the amount of regexp.exec in the figure) that might indicate that you
have a problem. combining the count with the exclusive time might help
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.
tip: pressing double click on a function line in the report can
break point and debug the function call.
Opinions expressed by DZone contributors are their own.