18

How would I go about determining what the hangups are in my javascript app when the profiler puts (program) at the top with 80%? Is my logic too complex for the hotspot tracking to occur? Is my memory footprint too big? What is generally the cause of this?

More Information:

Andrey Mikhaylov - lolmaus
  • 23,107
  • 6
  • 84
  • 133
Dested
  • 6,294
  • 12
  • 51
  • 73
  • 1
    You may want to check your javascript for any loops. Usually when you have that kind of usage it's from something that is just running as fast as it can in a loop. – Developer Feb 29 '12 at 06:07
  • 1
    You may consider uploading a screen-shot of profiler. – c69 Mar 02 '12 at 22:43
  • You may try debugging the browser itself .. http://www.mail-archive.com/chromium-discuss@googlegroups.com/msg06911.html But i would suspect your hot spots are in the DOM/Rendering/other(fileacces?xhr?) code, and not in JS. – c69 Mar 02 '12 at 22:52
  • All of the answers were incredibly helpful, but Alexander Pavlov's recommendation of timelines and memory profiling helped me track down the solution. I will try to post something here on my findings. Thanks again. – Dested Mar 09 '12 at 01:27
  • 2
    Please post; if possible, along with your comments of what was (or was not) useful in the DevTools, and what you'd like to be improved to make further diagnostics easier. – Alexander Pavlov Mar 09 '12 at 07:47

3 Answers3

25

Idle cycles ("doing nothing") will also render as "(program)" (you may profile this SO page for a few seconds and get 100% of (program)), so this is not a sign of something bad in itself.

The other thing is when you actually see your application lagging. Then (program) will be contributed by the V8 bindings code (and the WebCore code they invoke, which is essentially anything: DOM/CSS operations, painting, memory allocations and GCs, what not.) If that is the case, you can record a Timeline of your application (switch to the Timeline panel in Developer Tools and press the Record button in the bottom status bar, then run your application for a while.) You will see many internal events with their timings as horizontal bars. You will see reflows, style recalculations, timers fired, GC events, and more (btw, the latest Chromium versions have an improved memory profiler utilization timeline, so you will be able to monitor the memory used by certain internal factors, too.)

To diagnose memory problems (multiple allocations entailing multiple Full GC cycles) you may use the Profiles panel. Take a heap snapshot before the intensive part of your code starts, and another one after this code has run for some time. Then compare the two heapshots (the right SELECT at the bottom) to see which allocations have taken place, along with their memory impact.

Alexander Pavlov
  • 31,598
  • 5
  • 67
  • 93
  • 2
    An update: the **(program)** doesn't include idle time anymore. That's now being reported separately as **(idle)**. – Holger Stitz Mar 07 '16 at 16:03
3

To check if it's getting slow due to a memory option use: chrome://memory

Also you can check chrome://profiler/ for possible hints of what is happening.

Another option is to post your javascript code here.

Chibueze Opata
  • 9,856
  • 7
  • 42
  • 65
3

See this link : it will help you in Understanding Firebug profiler output

I would say you should check which methods taking %. You can minimize unwanted procedures from them. I saw in your figure given some draw method is consuming around 14% which is running in background. May be because of that your JS loading slowly. You should determine what´s taking time. Both FF and Chrome has a feature that shows the network traffic. Have a look at yslow as well, they have a great addon to Firebug.

I would suggest some Chome's auditing tools which can tell you a lot about why is this happening, you should probably include more information about:

  1. how long did it take to connect to server?
  2. how long did it take to transfer content?
  3. how much other stuff are you loading on that page simultaneously?

anyway even without all that, here's a checklist to improve performance for you:

  • make sure your javascript is treated and served as static content, e.g. via nginx/apache/whatever directly or cdn, not hitting your application framework
  • investigate if you can make use of CDN for serving javascript, sometimes even pointing different domain names to your server makes a positive impact, e.g. instead of http://example.com/blah.js -> http://cdn2.example.com/blah.js
  • make sure your js is served with proper expiration headers, don't re-download it every time client refreshes a page
  • turn on gzipping of js content
  • minify your js using different tools available(e.g. with Google closure compiler)
  • combine your scripts (reduces the number of requests)
  • put your script tags just before
  • investigate and cleanup/optimize your onload and document.ready hooks

Have a look at the YSlow plugin and Google PageSpeed, both very useful in improving performance.

Community
  • 1
  • 1
Somnath Muluk
  • 55,015
  • 38
  • 216
  • 226