I'm trying to do some performance/efficiency testing with Chrome Developer tools and their "Profile" tab...
I'm getting the following results When I load up the page, do a Heap Snapshot, refresh the page, Heap Snapshot, etc... repeatedly..
This question is 2 fold..
Is this normal? do I have a memory issue?
Can anyone point me to a resource to interpret the output of chrome's heap snapshot and cpu profiling?
This issue happens because you have chrome extensions that are retaining part of your DOM upon refresh for whatever reason.
When using the profile tools always go into incognito mode, no extensions are loaded here and you can be sure that the objects you see in the profile are only yours... well, mostly; you will also see chrome internal data structures wrapped in parentesis like (compiled code) or (system). Ignore those, you have no control over them.
Who would've said that incognito mode has other uses apart from... you know ;-)
It may or may not be normal. You'd have to analyze the difference between snapshots to tell.
Have you looked at the profiling docs?
Related
I suspect my one-page javascript app contains a memory leak somewhere. Weak devices running Firefox or Chrome seem to crash eventually if the page is left open. I'm trying to determine whether reloading the page would be expected to free the memory or not.
I understand that memory handling is specific to the browser, so the answer may differ in Chrome or Firefox.
NOTE: I recognize that browsers are mentioned a lot in this question (which would be off topic), but the point of this question is about javascript debugging, which I think is very on topic.
Barring browser/extension bug, browsers free up resources when they are no longer needed; Firefox clears compartments, Chrome kills processes and associated storage.
Firefox does its best but may take some time to clear the memory and may create zombie compartments on occasion:
Compartments are destroyed when they are garbage collected. This happens some time after the last reference to them disappears. This means there can be a delay between a page being closed and its compartments disappearing...
Sometimes, due to bugs in Firefox, the Add-on SDK and/or add-ons, compartments are created that are never destroyed. These are a particular kind of memory leak, and they cause Firefox's memory usage to increase gradually over time, slowing it down and making it more likely to crash.
Chrome uses a process per tab (and really subprocesses for some entities within a tab as well IIRC e.g. plugins, iframes, etc.) to the same effect. Though a quick check against chrome://memory-redirect/ and refreshing a tab looks like the same pid is used. So a refresh is not a completely clean slate.
FWIW Chrome has a "Force Reload" that clears the cache and might be either useful for clearing more memory or a placebo: cmd-shift-r
I'm not really familiar with the internals but I've only seen things not reliably freed up between refreshes when a particular browser is getting too clever and trying to preserve things when you're not changing origins etc. in an effort to boost load performance.
In short, you could be tripping up a browser bug if you're not seeing memory freed as you expect but you'd want to use the various "about:memory" tools to verify that and at that point it would be on you to avoid such behavior and/or report the issue to the browser's dev team.
Otherwise, I think you're best served by addressing your own memory leaks within the page using the various tools available.
A good way to debug the resource usage of JS is to use the Firefox performance monitor within the inspection tool. Firefox Dev Edition has more in-depth tools
Press F12 when on the page and click on the little speedometer icon in the inspect window; this will open the performance monitor. Press the "Start Recording" button and Firefox will begin to benchmark all script timings, CSS activity, user input etc. on the page.
When you feel that it has been running for long enough, stop recording and you will be presented with all the data. At the top will be a chart displaying performance and you can click on any part and examine all the scripts running at that time.
A full tutorial for the performance tools can be found here
My website (www.transferxl.com) relies on Javascript for compressing data. Compressing a 25MB large chunk takes about 1-2 seconds with most browsers (Chrome, Safari, Firefox, ...). IE11 takes over 40 seconds for exactly the same operation.
I thought IE11 was just painfully slow, so I decided to enable the profiler and see what is happening. To my surprise the same chunk was compressed in 2-4 seconds. Although still slower than Chrome, it was way faster then before.
Steps to reproduce:
Go to www.transferxl.com.
Open the developer console (F12).
Add a (compressible) file that is larger than 25MB.
Transfer the file and watch the console
You'll see a message how long it takes to compress the chunk of data.
Refresh the window (while still on www.transferxl.com).
Start the profiler.
Add a the same file again.
Transfer the file and watch the console
You'll see that the same block is now compressed much faster. You can also try it in reverse order. Results are stable. With the profiler on IE seems to compress 10-20 times faster then without the profiler.
Does anyone know what could be the problem? The profiler output doesn't show anything alarming. Has anyone else seen this issue?
I have tried doing exactly what you asked, and the uploads took less than 2 seconds on both Google Chrome (39.0.2171.65 m) and Internet Explorer (11.0.9600.17420). It appears as if Microsoft may have released this fix in one of their more recent updates. As far as I have seen, nothing of this sort was mentioned in the changelogs. Yes, I ran IE with the profiler disabled. I presume that the issue may have been caused by IE assigning process priority to scripts running with the profiler attached, since the profile also needs to function and render its output (supposedly) without affecting the functioning of the page itself. The compensation does not noticeably affect the computer's processor consumption in any way, but somehow just utilizes existing memory that has been allocated by IE prior to opening the profiler.
I've built an application that wastes 40% of its time collecting garbage, and I'm at my wits' end trying to find out where it is coming from. I've corralled any possible problems in my own code, yet it persists. I'm beginning to suspect some third party code of being the problem, and I'd like to know if I can somehow track down what is being garbage collected. If there's a Chrome-specific answer, that'd be great, but I'll take anything at this point.
In Chrome I would start with following:
DevTools > Profile
Take Heap Snapshot
Working with the application
Take Heap Snapshot again
Inspect the second snapshot in the comparision mode
Following links may be useful:
http://addyosmani.com/blog/performance-optimisation-with-timeline-profiles/
http://rein.pk/using-the-heap-profiler-in-chrome-dev-tools/
Perhaps you could try Chrome's Heap Profiler?
Also, related questions to Javascript Heap profiling:
Chrome HTML Page Memory Usage
Forcing garbage collection in Google Chrome
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
I use Firebug and the Mozilla JS console heavily, but every now and then I run into an IE-only JavaScript bug, which is really hard to locate (ex: error on line 724, when the source HTML only has 200 lines).
I would love to have a lightweight JS tool (a la firebug) for Internet Explorer, something I can install in seconds on a client's PC if I run into an error and then uninstall. Some Microsoft tools take some serious download and configuration time.
Any ideas?
You might find Firebug Lite useful for that.
Its bookmarklet should be especially useful when debugging on a user's machine.
Since Internet Explorer 8, IE has been shipping with a pretty impressive set of tools for JavaScript debugging, profiling, and more. Like most other browsers, the developer tools are accessible by pressing F12 on your keyboard.
Script Tab
The Script tab is likely what you'll be interested in, though the Console, Profiler, and Network tabs get plenty of use as well while debugging applications.
From the Script tab you can:
Format JavaScript to make it more readable
Move from source to source of various resources on the page
Insert breakpoints
Move in and over lines of code while stepping through its execution
Watch variables
Inspect the call stack to see how code was executed
Toggle breakpoints
and more...
Console Tab
The console tab is great for when you need to execute some arbitrary code against the application. I use this to check the return of certain methods, or even to quickly test solutions for answers on Stack Overflow.
Profiler Tab
The profile is awesome if you're looking for long-running processes, or trying to optimize your code to run smoother or make fewer calls to resource-intensive methods. Open up any page and click "Start profiling" from the Profiler tab to start recording.
While the profiler is working, you can move about the page, performing common actions. When you feel you've recorded enough, hit "Stop profiling." You will then be shown a summary of all functions ran, or a call tree. You can quickly sort this data by various columns:
Network Tab
The network tab will record traffic on your site/application. It's very handy for finding files that aren't being downloaded, hanging, or for tracking data that is being requested asynchronously.
Within this tab you can also move between a Summary view and a Detailed view. Within the Detailed view you can inspect headers sent with requests, and responses. You can view cookie information, check the timing of events, and more.
I'm not really doing the IE Developer Tools justice - there is a lot of uncovered ground. I would encourage you to check them out though, and make them a part of your development.
I would recommend Companion JS.
This is the free version of Debug Bar but I find it easier to use and have the features I need. Great to test little JavaScript snippets in IE the same way I do with Firebug in Firefox.
EDIT 5 years later: I now uses Internet Explorer integrated developer tools.
IE 8 is supposed to have better tools, but the IE Developer Toolbar is pretty good.
I use both Microsoft Script Debugger and FireBug Lite, depending on what I am debugging. Both are great tools- try them both out and stich with what you're comfortable with.
In IE8 just press F12!
Go to Tools->Internet Options…->Advanced->Enable Script Debugging (Internet Explorer)
then attach Visual Studio Debugger when an error occurs.
If you're using IE 8, install the developer toolbar because it has a built in debugger.