I'm trying to understand where the time is spent in my JS code so I can improve its performance. The "Performance" tab of Chrome's developers' tools gives me much of what I want, allowing me to narrow things down to the function that is taking most of the time, in this case JQuery's "find" function.) However, when I go to the "Event Log" view, it doesn't seem to show all of the function calls and their execution time. I think that the reason is that Chrome is sampling the state of the code, rather than tracing each function call, and so the information is not available.
Is this correct? If so, is there an easy alternative that doesn't require me to manually instrument all my calls?
I found the "Web Tracing Framework" which sounds like it does what I want, but installing the extension and trying to analyze a trace didn't work right off the bat. I started digging into what was going on, but there are several known issues and the code doesn't seem to be actively maintained. If someone can tell me it works fine, I'll be more persistent.
Otherwise, what do people use for this now-a-days?
Related
There is a certain spot on my page (a jquery based web-app) where it kind of hangs. Are there any tools that would quickly determine if there's a specific place it's getting tripped up?
It is on localhost right now, which may alter what tools would be applicable. (I'm not talking about load time, but rather execution time)
Have you seen FireBug?
Firebug for Firefox and Developer Console for Chrome both have built in script profiling tools that will help you identify slow logic in your JavaScript programs.
There is jQuery deep profiling plugin by John Resig. There's also this article from him that talks about Function Call profiling.
There is also this great tool called dynaTrace which gives you the ability to profile in IE (and FF). It provides lot more than simple JS profiling (like DOM rendering measurement) and is quite useful.
Use Firebug, just call:
console.time("timing foo");
Before executing the code you want to measure and:
console.timeEnd("timing foo");
Afterwards. That in a low-fi approach.
The high-fi would be just call console.profile() before the code you want to measure, and then console.profileEnd() afterwards.
DynaTrace is by far the best thing I have seen out there... its Free to use too.. And the best part is it works for IE too where the performance is worst hit. A brilliant application with all performance measures.. needs a little bit of learning but once you are used to it there is nothing like it out there...
it also measures network time in ajax requests.. apart from this the rendering time etc.. it can go deep into JS libraries like Jquery..
Try it!!
Is there a way to check the resource usage with a javascript code?
Can i check RAM usage and cpu usage of the script?
Since there are various ways to do something, i might write the code using different methods, and save it in as 2 different files, and check which method is more optimized. Esp when i'm calling a function recursively.
This way, i'll get to learn which methods are better and what to use.
Anything like maybe an addon, or maybe a script to be added that does this. It would be much better if it shows function wise. I'm not sure if something like this exists.
On a note, with chrome inspector, i tried CPU profiling, but it seems to show me values according to time, and does not show the RAM/CPU usage.
There's no uniform cross-browser way to do this. You can get an overall sense of your javascript performance by using Chrome's Timeline tool. Switch between the Timelines and Memory tabs on the left and hit the record button at the bottom. I believe Safari has a similar tool.
Internet Explorer has the excellent DynaTrace tool, although I don't know it well enough to provide detailed instruction on how to use it.
Note that javascript interpreters vary wildly in implementation, so they may have very different performance characteristics. Rather than get caught up in the details of implementation (premature optimization is evil and all that), write your code with good coding practices in mind. That means that if you do have performance bottlenecks (which the profiling tools available will help you locate), you can refactor more readily.
I don't know any specific way to test the Ram and CPU stats of javascript. But I often user http://jsperf.com/ to see how two different functions perform.
Have you tried with Crome Tools > Task Manager in Chome Tools menu options? It shows the CPU and Memory Usage for each process running in the borwser (comprise chrome-extensions).
So tried my hand at profiling some code and I figured the easiest way to do it (at least on Firefox) was to use either console's time/timeEnd or profile/profileEnd, and I tried both.
The problem I have is with the number of runs I can do before Firefox crashes on me. Now I won't paste the code here because it's typical benchmarking code (and it's very messy), but obviously the gist of it is that it runs functions (a test is represented with a function), logging their execution time for a certain number of runs.
Now with for example, 5e4 it sorta works but I don't think it's enough to spot (very) micro optimizations, but more than that, it crashes.
So how do you profile your JavaScript? Because this way, it's barely feasible.
When I used to profile my JavaScript code I used Chrome's profiler; the JavaScript Console in the developer view gives it, and it pretty much worked for me. Have you ever tried it?
I have tried profiling a page with a lot of scripting in Firebug on FF4 and the same in Chrome (last version). Firefox crashed within a second or two, Chrome didn't seem to have problems with it. Maybe you can find something on it in the Firebug issues list?
Although not a traditional code profiler, I recommend Google's Speed Tracer:
Using Speed Tracer you are able to get a better picture of where time is being spent in your application. This includes problems caused by JavaScript parsing and execution, layout, CSS style recalculation and selector matching, DOM event handling, network resource loading, timer fires, XMLHttpRequest callbacks, painting, and more.
I think the profiler in the JavaScript Debugger (aka Venkman) is quite good. The version currently on addons.mozilla.org is not compatible with Firefox 4, but the change necessary to make it work has been committed. See https://bugzilla.mozilla.org/show_bug.cgi?id=614557 for details.
dynaTrace AJAX edition(free)- one more tool in your bag. Offers a little bit more detailed performance metrics, IMHO. They used to have it only for IE, but their new one supports FF too. Also see Steve Sounder's blog
My pages seem to be reacting slow.
There is a lot of JavaScript (jQuery) code on the page. How can I narrow it down? What is taking so long?
The YSlow add-on is the best solution to know why your website is slow.
There are many issues which could be the reason for slowness.
Combining many jQuery to one could help you increasing your performance.
Also you can put the script at the bottom of your page and CSS at top.
If you use Firefox, you can install Firebug and use the profiler.
You can read more about it in Understanding Firebug profiler output, and there is a tutorial in Firebug Tutorial – Logging, Profiling and CommandLine (Part I).
If you use Internet Explorer, you can use dynaTrace Ajax edition.
Read more about it in A Step-by-Step Guide to dynaTrace Ajax Edition, available today for public download .
There's also a built-in profiler in Google Chrome that you can play around with.
Both these solutions will help you narrow down what JavaScript function calls are the most costly, and with repeated profilings you will be able to see the effect your changes has.
Using tools like these will not only make you a better programmer (if you take the lessons to heart, and avoid the same mistakes they point out in the future), they will also give you a new appreciation of what happens in your code, since you will get a behind-the-scenes glimpse you haven't seen before ;)
Also, if you don't know YSlow, like Wazzy is talking about - get to know it... maybe your problem isn't even slow JavaScript code :)
Working with Extjs, GeoExt and OpenLayers, I more and more tend to run into problems which do not result in direct javascript errors (in either IE, FF or similar). It could be features not working, unexpected behaviour and so on.
My usual strategy is to strip down code to a minimum hoping to discover where the problem arises - Firebug and the IE debug tool are usually great companions. Google and various forums are always a big help – IF a similar problem has been documented by another user and IF the problem has been formulated in a way so that I find it.
But when it comes to using larger frameworks such as Extjs and OpenLayers, I find it very difficult when my debugging leads me inside the frameworks world of mysterious methods.
Asking questions here and in other forums can give fantastic results, but sometimes I cannot point to what the problem actually is – only the result I see on the screen. Using multiple frameworks it could be interference between them, unexpected behaviour when using exactly those frameworks and generally just complicating the debugging.
What do you recommend I do in these situations? What do you normally do – I would love to pick up a trick or two :)
I feel your pain. I use YUI a lot and sometimes errors get sucked into a bottomless pit of YUI code that doesn't generate an error per se but also doesn't do what I think it should.
In cases where I'm lucky enough that an error is thrown inside foreign code I look at Firebug's call stack and start debugging at the first place up the chain where I find my own code.
In the case of the bottomless pit swallowing errors then I resort to setting breakpoints in my code at suspicious places and single-step my way through.
Firebug is very, very useful here since it allows you to dynamically set breakpoints and conditional breakpoints. In both cases above I never reduce my problem to a minimum because the bug may be due to the complexity. Also, setting breakpoints is much easier.
About the only time I reduce my problems to a minimum is when I need to post it here or at comp.lang.javascript.
Now, if the bug only appears in IE I usually give up for the day, go home and come back tomorrow. It is a surprisingly effective strategy until my boss decides that we need to push the code to live TONIGHT (in which case I just cry inside).