Join the DZone community and get the full member experience.
Join For Freelately i’m involved in a very interesting project which suffer from
javascript performance issues in old browsers. the main “pain” in the
project is the need to support ie8 which is used by many of the client’s
users. i’ve got a call to come and help in the process of tuning the
application and decided to share some tips of how i profiled the
application and found some of the bottlenecks in the application
javascript execution. those bottlenecks were handled by the development
team very fast and the application’s execution is becoming much better.
since the main problems were mainly in ie8 then i used ie developer
tools in the process and not firebug.
starting a profiling session
the first thing that you’ll want to do when you profile javascript is
to setup your environment. first open the relevant web page in ie and
press f12 in order to open the ie developer tools. in the developer
tools, change the browser mode and document mode to ie8 and ie8
standards respectfully like in this figure:
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
to find bugs in the javascript use.
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
take you to the javascript source file (if exists). then you can set a
break point and debug the function call.
summary
profiling javascript isn’t as simple as it sound. using profiling tools like in ie devloper tools (which i used because ie8 was giving hard times to the client) or firebug can help to simplify this matter a lot. knowing how to read the reports will probably help to fine tuned the code you wrote.
Topics:
Opinions expressed by DZone contributors are their own.
Comments