A website I'm working on crashes in IE8 through 10. I have been trying to determine if it is related to a memory leak, but the tools available for IE are not really great. I've tried using Sieve ... as well as dynaTrace ... Sieve reports no memory leak, but does report on multiple orphaned dom nodes. dynaTrace does not support memory analysis in IE, and the issue does not seem to present itself in Firefox.
I've reviewed heap snapshots in Chrome Dev Tools... and garbage collection seems to be fine there after about 10 seconds or so of the site loading.
Here is the site in question: http://midlandsbiz.whosonthemove.com/
After several minutes on the site in IE, my AVG will pop-up saying that it is consuming too much memory. This is also evidenced by my fan whirring on my laptop, and the ultimate crash of the site.
This happens on multiple computers, on different networks, using different versions of IE.
I was also able to replicate the issue using the WP theme author's site:
http://kopatheme.com/demo/passion/
I'm getting no response / support at all from the WP theme author about this issue.
I was hoping that someone had some ideas on what might be causing this... or could point me in a direction for some tools that I can use to profile javascript memory usage in IE?
You have some major memory leaks and a HUGE memory footprint. There are actually great memory profiling tools in IE, just open F12 and choose the memory profiling tool. You will want to start a profile. When you take a snapshot you will get a simple visual telling you the size of the page in memory and how many objects. When you have a memory leak you will see a blue circle with the number of leaks. Clicking on that will take you to a view of the objects and you can swim through the tree to find the source of your issues.
I can also tell you have many fundamental performance issues in the site. You have over 200 HTTP requests and 4MB of content. You also have many 404s.
Related
I'm working with a team on a single page application with quite a few timers, and about 10 REST API calls per second. We've used the Chrome memory profiling tools to locate all of our memory leaks--at this point the heap size stays about the same (i.e. in between garbage collections).
However, we're noticing that the longer the application runs, the more memory the Chrome tab itself uses. After a few hours, we've seen the tab memory grow to about 350MB, while the heap size remains at 6MB. If run overnight, the tab consumes over 500MB and becomes unusable by morning.
We need the application to run for long periods of time (we're hoping to restart it only once a week), so this is a problem.
Here's a screenshot of the heap timeline over the course of an hour. At the end, the tab's private memory size is 350MB, while the heap's size remained at around 5.4MB.
We've seen this in Chrome 40 and Chrome 38, on Windows 7. We have caching disabled, and are running the application in incognito mode.
Any idea why the tab memory size would grow to the point where Chrome is unusable, while the JS heap usage remains so small?
EDIT: We ran the app for a couple days and the tab memory size is up to 800MB, heap size still about the same.
EDIT (6/9/15): I'm not sure if this is documented anywhere, but it seems like Chrome changes the amount of memory it will allocate to a tab, based on the amount of free memory on the system. So, if you have a lot of free memory, tabs will use a lot of memory, and if you don't have much, it won't use as much. This doesn't seem to be proportional to heap size, it's probably just stuff that Chrome keeps around to make itself faster. This is only a theory, based on monitoring Chrome memory usage :)
This is probably too old and not relevant anymore, but for everyone else who experienced this: it's probably because of the opened dev tools. I had an application that would accumulate memory over time with the heap size staying the same, but when I closed the dev tools the memory went way down and didn't get back up like it did when dev tools was open. When profiling long term memory footprint, use chrome task manager first.
I can guess that in your case it happens because devtools has to store all those REST API calls (to show them in Network tab) and I'm not sure if chrome saves them to disk temporarily to save memory.
I'm running some memory usage tests in a WebGL project that I have. If I start the page on Google Chrome and take a heap snapshot on the Profiles tab of Developers Tool, it will say that my page is holding 7.5 MB.
The problem is if I look into Task Manager, the real value that it is using is almost 1 GB! It is expected, since I am really forcing the page to have thousands of objects, but the question is: why Chrome shows to me that I am using only 7.5 MB?
update
there was native memory snapshot that was able to show you the native memory graph.
Unfortunately we removed it because it was a fragile piece of code.
It required nontrivial instrumentation in hundreds of classes and affected the binary size.
I hope we reimplement it later.
was
It takes a snapshot of Javascript heap. All your javascript objects use 7.5mb. This size doesn't include images, canvases, audio files, plugin data, etc.
There is a native memory snapshot in DevTools.
It counts non-javascript memory used by the renderer process but this is an experimental feature.
You need to enable DevTools experimental feature in chrome://flags, restart the browser, enable Native Memory Profiler experimental feature in DevTools settings panel and reopen DevTools.
After all these steps you will be able to take Native Memory Snapshot in Profiler panel.
Not all the memory chunks in the native memory heap are counted but we are working on that.
Please use the Canary version of Chrome.
It updates every day and works side-by-side with other versions of Chrome.
If your page eats gigabytes of memory and has big "Other" bar, more than 10%-20%, please drop a mail about that to the Google Chrome Developer Tools Foums.
You can still take snapshots under the profile tab and click take head snapshot which gives you in-depth memory usage stats.
We are creating a Chrome application that we hope to release in the coming weeks. We have already distributed to a bunch of alpha testers, and, even though feedback is generally good, we have had complains by a bunch of users that our extensions is expensive in terms of RAM.
We also had reports of a too high CPU consumption.
Now, we have improved what seemed obvious, but we are almost 'blind' in terms of execution.
What would be the good strategy to profile both memory and JS calls for our Chrome application?
Please note that this application is a full native application, so maybe we can apply some generic javascript profiling tips?
As people have mentioned, you can use the Chrome Developer Tools to profile memory usage.
For CPU and RAM, it's not particularily scientific, but you could get a broad gauge by having no applications open other than Chrome which has about:blank open and your OS' Activity Monitor or Task Manager.
Look at the CPU and RAM readings for Chrome on about:blank, which is about as idle as it will get - then compare that to the readings when your Application is running.
Disable all extensions too, to take them out of the equation.
Hope this helps.
I have a large, javascript heavy web app that I am working on. I am experiencing very slow response times from Chrome Dev Tools for XHR responses and console loggging (3-5 secs). The actual app is running fast and responsive, only dev tools looks like it is suffering.
Does anyone have any idea why Chrome Dev Tools is becoming sluggish as my app grows?
Devtools are like any other debugger; they hook into the normal processing flow of an application, and store quite a bit more information than is normally required. This is much more work than simply rendering the page without debugging enabled, so it will indeed be slower.
That said, 3 seconds to respond to console.log seems high. I'd suggest that you first test the application in a nightly version of WebKit. If it's responsive in WebKit, but not in Chrome, please file a bug against the inspector via http://new.crbug.com/ along with any information you can provide about what scenario causes the slowness.
If it's equally sluggish in WebKit, please file a bug against WebKit's Inspector component: https://bugs.webkit.org/enter_bug.cgi
Either way, post the bug ID here, and I'll see that it's triaged into the correct team.
I "fixed" the slow chrome developer tool by (under SOURCES tab)
clearing the "watch" list that accumulated over time...
clearing all the "snippets", i had dozens as well...
Not sure which of both made the most difference, but it certainly made a difference
This is an old question, but it may help someone landing here later like I did.
Using Chrome 46.x/47.x on Linux (RHEL 7), none of the proposed solutions worked for me. What did work was to disable the setting "Use hardware acceleration when available", in the advanced browser settings.
I noticed in the process monitor/list that the Chrome renderer was taking up a lot of CPU, even putting a breakpoint or stepping throught statements in the debugger would take 10+ seconds!
Might be worth a shot.
Undock the developer tools into separate window.
In my case, it's work.
I struggled with this also, to the point where stepping through code using the chrome debugger was just so slow it took hours away from my productive development time. In watching the CPU utilization when debugging in chrome I would see it use up to as much at 40% of all 4 cores of my processor. I tried everything to no avail. Finally, I tried making the browser window of the page I was debugging as small as I could without losing any of the required view and miraculously it solved the problem. So, now I keep my debugger window popped out in a separate window, and make the window of the page I am debugging as small as I can and my debugging experience is very fast again. I have tested this over a period of weeks and it has held out. Hope this helps someone.
I've lately been running into odd issues, which I'm starting to think are related to resource starvation in the browser.
In FF:
I'd been testing one of our web apps and suddenly things that should disappear after a couple seconds stopped disappearing. I tracked back to setTimeout just flat out refusing to work. After reloading the browser it was all clear, no issues.
In IE:
I regularly see issues where IE will refuse to do transparency all the sudden, simply reloading the page clears this up.
In both:
Though I can't say its related for sure, I see unexplainable behavior, things along the lines of variables not being available (undefined) when they should be.
Both browsers also show a steady increase in memory usage over time (memory leaks).
The javascript in the web app is heavy and it is a single load page (making those memory issues mentioned all the more painful). There are lots of in-efficiency, and various things that make one say "why would you do that?".
Has anyone encountered such things? Can you point out general resources that will help identify and resolve these issues?
You could try running your application against the Chrome Profiler http://code.google.com/chrome/devtools/docs/overview.html. You can profile the CPU and get snapshots of the browser heap, that should help locate any rogue stuff.
If your application is designed to work with the Internet Explorer: The Developer Toolbar also has a profiler.