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.
Related
In latest Chrome DevTools I can see a new information:
Now, I'm not sure how to use this information. It seems to appear randomly in the app. How can I debug the app to avoid potential out-of-memory crashes? I checked in task manager that at the moment when this information appears the app uses about 55K memory which in case of this app is quite low (when it computes some data it can be much higher memory consumption).
So I'm wondering if this information is accurate and there is a risk of crashing. If so, what should I do with it?
Record a profile with memory tab in chrome dev tools. You can investigate there which functions consume memory
Here's a great guide:
https://developer.chrome.com/docs/devtools/memory-problems/
Maybe this is late and very obvious, but you can use the "Memory" tab in the Chrome developer tools to create a memory snapshot while loading/browsing your app in order to investigate what is eating up your memory (given that it actually is your app that is eating up the memory).
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.
I am having a problem trying to articulate what I am trying to measure but I would do my best in hope for some assistance.
If I would to bind alot of functions to the .resize() event or to add massive amount of listeners, somehow I believe that the cpu processing would increase and that at a certain point the application would lag. (Do correct me if I am wrong).
I am attributing this to the CPU usage(Please correct the term if it is wrong).
Is there anyway to measure this lag(cpu usage).
Thanks
In Google Chrome's Developer Tools there are timelines for recording memory usage and CPU profiling. Lots of good examples on the web for how to use these tools.
You can monitor your browser in TaskManager if you're using Windows.
JavaScript executes in the browser, so it will be part of the footprint of the browser itself.
Some times different browsers will run the same JavaScript with different performance. It just depend how optimized the browser is for that particular code block.
Most browsers will also give you profiling tools that will enable you to pinpoint specific JavaScript functions that are slow. (ex IE dev tools). This is necessary to take a more targeted approach when troubleshooting your performance issues.
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.
We all know how web browsers (such as Firefox) are certain to fill up memory consumption because we continuously execute JavaScript code (from websites) that is prone to memory leakage.
I am debating in developing a Desktop app, and given my experience with Javascript/Css/HTML, I thought I would give AIR a try, this way I don't have to use Java (for example) and deal with learning all its GUI swing stuff.
The problem is that I worry about memory leakage in AIR, since AIR is simply a web browser with an API layer to interact with the Operating System.
Is it plausible to worry about memory leakage in AIR? What should I do about it?
My name is Rob Christensen and I am product manager on Adobe AIR. First, let me say that it is quite easy to build a desktop application, regardless of underlying technology, that consumes a large amount of memory and/or does not free up memory.
In the next release of AIR, we are looking at providing some additional capabilities to the AIR runtime to make it easier to identify memory leaks for JavaScript-based applications. Developers that are building Flash or Flex based applications can already take advantage of the memory profiler included in Flex Builder to track this down. We are hoping to do something similar for JavaScript developers as well.
In my experience talking to developers, memory leaks often occur when objects in memory are never cleaned up. For example, imagine a Twitter client that lists tweets from users based around a search keyword. Overtime, more results show and the list becomes longer. If there is not a limit on the maximum number of Tweets visible, memory will, of course, go up over time. Instead, the application should impose a reasonable limit on the number of items that appear in that list.
There are some talks available that describe best practices around handling memory in AIR. Though the examples in this article are mostly written in ActionScript, the same concepts apply to JavaScript as well.
Performance-Tuning AIR applications
http://www.adobe.com/devnet/air/articles/air_performance.html
If there are memory leaks in the runtime, we jump on these as quickly as we can. We encourage developers to know about such issues by sending them back to our team using the following feedback form (www.adobe.com/go/wish).
If you are using an Ajax framework, you may want to look into whether there are known issues with memory leaks for that particular framework.
So, to summarize, yes, you should always worry about memory when building a desktop application -- whether with AIR or C++. As you are developing your application, you should monitor the memory usage of your application so that you can identify any issues sooner than later. One way to do this is to run longevity tests -- keep your application open over night to see if memory is creeping up.
In general, the tools available for browsers are very limited as well. I expect this will change soon as browser vendors also start providing more hooks into their browsers for identifying memory usage. Hope this helps.
Thank you!
-Rob
Product Manager, Adobe AIR
Sure. I've seen AIR apps on Linux swallow gigabytes of memory over time. It's a real blocker for me and stops me using them.
That said, other people on other platforms have no issue with it. Ultimately you need to decide what most of your market will be using and how affected they'll be by any issues in AIR (or other).
If it's not that important (but it's still an issue) submit bug reports and hope Adobe fix things.