I have a strange situation and I need some ideas.
"Sometimes" I have a performance issue when I am destroying a dom/web component. I am using Google Chrome.
I wanted to see with the profiler what is going on and strangely if I enable the Performance Profiling everything goes well and fast.
I guess it might be an extension I use that is causing the issue, but how can I identify it, without enable/disable all of them?
This screenshot will give you an idea about the response time differences. The second request takes longer (there is more to destroy).
Related
I have more general question on how you usually approach on debugging page with tons of javascript (mostly third-party add-ons) and event watchers to discover the problematic line, which in my case causes the Chrome to crash or Firefox to freeze?
I have a landing page with many external dependencies: the usual suspects like jquery and bootstrap, but also many add-ons like sliders, re-size watchers. When I re-size there is a micro-freeze on Firefox and a crash on Chrome. This is from any block of code (some watchers most probably).
After page crashes I lose all of my dev tool data. Firebug doesn't have the timing control over scripts execution, and if I start with breakpoints I have to put dozens.
How you usually proceeding to identify the script that causes the problem and further more the block of code?
If I start with breakpoints I have to put dozens.
I used to have this problem a lot back with Internet Explorer 4/5. Those browsers made such poor use of memory that almost any significant error wold result in the browser crashing. And even before it did, the browser debugging tools were far, far worse than the Chrome ones. So what did I do? Sadly, debugger and console.log.
You must have some idea, or ideas, as to where the problem lies, so just start at wherever you are certain your code is working and add a console.log (if you can still see the logs up to the crash) or a debugger (if you can't) to every point along the way to the crash. Eventually you won't make it to one of your debugging statements, and then you'll know that the problem is in-between that statement and the previous one.
It's a really lame way to debug, I know, and as you said you will have to add a lot of debugging statements, but sometimes it's all you have.
I have written a website that relies heavily on Javascript/jQuery and HTML5.
Unfortunately I occasionally experience complete browser melt downs. Because the entire browser dies on me I am finding it very hard to pin point if I have done something to cause this.
I have no infinite loops, Ive been carefully trying to make sure there are no memory leaks. Another problem is that I cant recreate the issue on command. Doing the same things in the same way and order as what caused the crash last time, wont make it crash again.
I am not entirely convinced the issue is my website, but it does seem to happen more often when I am browsing the site. These crashes have occurred in the latest stable released of Firefox and Chrome.
Is there anything I can do to get some valuable debugging information when the browser dies?
And is there any software additional to things like FireBug which I can use to specifically hunt down any memory leaks?
Does your firefox try to send a crash report to mozilla? If so, I believe you can view your own crash reports somewhere on the mozilla site. I'd look it up, but am running out of time here.
p.s. lacking reputation to make this comment, it is answer instead >.>
The project I'm working on involves a "planning" screen, which is entirely made with backbone.js (the other pages of the app are not).
My issue is that from times to times, chrome freezes and the web view stop responding to any interaction. Sometimes, I can manage to quit chrome itself, but usually the controls does not answer either.
I'm pretty convinced this is related to the js code. It seems to me that when a script takes too much time, or loops indefinitely, Chrome can detect this and interrupt the script. However, since this is not the case, I'm thinking that too many js objects stay in memory.
Whatever the cause is, I would like to know which chrome dev tools can help me here. While I'm not a beginner in js, asides setting breakpoints and calling console.log, I have no idea how to debug JS apps. I'm not opposed to use another browser if the dev tools are more suited.
Thanks a lot for your time !
FTR : This is a rails 3.2.8 app, using mongodb, & Backbone.js 0.9.2. The js code is written in coffeescript. This issue happened on my macbook air 2012 running mountain lion, as well as on the client machine which runs on windows 7. The issue appeared at least on chrome 22 & 23.
Using the Javascript CPU profiler, I was able to find the group of functions that seems to be responsible for the freezing.
I'm still open to any advice/ressource on debugging javascript code.
Make a console.log in the loop and check if its the same point freezing on all chrome versions. There is a limit see Browser Javascript Stack size limit.
Maybe add some code? Because there could be some memory leaks especially with event handlers!
What I would do is the long and weary approach to getting your hands dirty with console.log. --- in this case.
In your case, and THX for the hint by the way (finding the offender with the CPU profiler, I'll try that next time round), I guess the offenders might be some functions "callbacking" themselves .. probably via some sort of event-handling/bubbling/callback-combination.
What happens then usually is that it just doesn't recognize the endless-loop, because the callback-stack is kinda "broken". Therefor it will never throw a browser-error.
If you have any luck, it doesn't kill the browser quick enough to kill the console. I did have that at times, the console killed (remaining silent), the coffeescript files not even loaded in the debugger (I use a JIT-coffee-to-js-translator as in JS-MVC) ... the page frozen or not doing anything ...
So, if indeed you are lucky and the debugger spits out your console.logs you can thereby guess where your unwanted loop is hiding. Just by looking at the repeated order of the output statements.
of course you know you can set breakpoints right? even conditional breakpoints
I'm currently struggling a bit untangling a similar sounding loop - i guess in case of emergency some alert() calls in your code would at least slow the loop down
or maybe some wait calls (bad idea)
my loop is running so fast I loose my console log!
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.
I do a lot of ajax calls on my site and was using jQuery 1.4.2 until I noticed that it was leaking. It was leaking with IE, Firefox, and Chrome. After some investigation I found the IE fix for it. I tried it but it didn't fix it for any of the three browsers. I then found a posting on here where the person compared Yahoo's Javascript library to jQuery. Yahoo's didn't leak for that person. I switched to Yahoo's and it did stop the leak in IE and Firefox (I even used the Firefox leak addon). But Chrome is still leaking. Chrome builds up to around 200MB of memory and then crashes my tab. The ajax call is every second. It takes about an hour before the tab crashes. If I leave the page the memory is released. Again, IE and Firefox the problem is now gone.
What's the best way of determining where the problem is for Chrome? I looked for an add-on but haven't found one yet. I also did some searching on Google but haven't really found anything there either. I took heap snapshots but I just see big numbers next to (closure) and (code).
I liked the Firefox one (Leak Monitor), made it easy to see the problem. Anything like that for Chrome or any suggestions for finding the leak?
Use Chrome's built-in Heap Profiler in DevTools (press F12 in Chrome then go to Profiles tab):
Here you can find how to test it:
link
The framework isn't causing the leak, it's your code. Let me guess at what your code looks like.
$.get('//url/',function(){
//lets do fun stuff!
function(){
//more fun expensive stuff for the browser to do
}
};
//A more efficient way (doesn't create closures)
function expensivefn(){
//Do expensive stuff here
}
$.get('//url',expensivefn);
This is only one possible way your code could be inefficient. I don't commonly create pages that infinitely loop, usually I look for a set amount of time then ask the user if he still wants to poll. The loop you are using could be creating unnecessary closures just like the above example. For example,
//Bad!
setInterval(function(){
//Expensive stuff
}, 1000)
//Good
function expensivestuff(){
//Expensive stuff
}
setInterval(expensivestuff,1000);