This week's book giveaway is in the OCAJP 8 forum. We're giving away four copies of OCA Java SE 8 Programmer I Study Guide and have Edward Finegan & Robert Liguori on-line! See this thread for details.
"Fortunately, finding jQuery memory leaks is easy. Check the size of $.cache. If it’s too large, inspect it and see which entries stay and why."
Sounds simple enough, but the page doesn't explain how to do this. How to inspect? What is "too large"?
Can anyone guide me on this?
Are there any third-party tools designed to identify memory leaks?
"The good news about computers is that they do what you tell them to do. The bad news is that they do what you tell them to do." -- Ted Nelson
It's on the client side. We have what we call a Slide Show application. It displays pages in kiosk mode in a constant rotation. This app has been in use for several years and it runs pretty clean. Restarting the systems once a week keeps them clean enough to avoid IE errors.
This latest page they've sent me runs in a loop with 3 different sets of parameters (displaying 3 groups of machines). The IE memory usage starts at about 40k when the slide show first loads, but with every page load the memory footprint (via task manager) increases by at least 10k. Within an hour or two, IE is consuming over half a gig of memory. If I leave it running all night, it will be locked up by the time I get here in the morning. The CPU utilization is still negligible, but IE has consumed pretty much all available memory.
I've tested it with a program called sIEve, and it says "leak, leak, leak" like crazy, but I'm having a difficult time identifying what it's complaining about. Now I've switched to the profiler in the Chrome Developer Tools and following a tutorial for that, but this is challenging, to say the least.
Bear in mind that testing in chrome may not help find leaks that may only manifest themselves in IE. IE -- especially older versions -- has leak problems of its own. Do you experience the problem in all browsers or just IE?
Of course, there are a bazillion other things that can go wrong too.
You know long long time ago before we had nice memory analysis tools that showed you howmany objects were allocated, I had come up with a trick to identify memory leaks. I called it "finding memory leaks using binary search". SImply put, I would comment out half the functionality and test the app the see if memory usage increases. If it does, the problem is in the code that isn't commented out. If it doesn't, the problem is in the code that is commented out. Take the code that has the problem, comment out half of that and repeat till you find the culprit. Many times, the problem is in multiple places, and this helps you find one place. So, once you fix the problem, you have to go back and repeat the whole process again.
It's an exhausting way of solvin memory issues. However, when tools fail you, you have to just grin and bear it. Also sometimes, disabling parts of functionality changes the way other code behaves. So, you have to mimic the functionality that you comment out
Thanks, Jayesh. As soon as I read your post I realized that I don't need all that timer code. This page was designed to be left open on a desktop so the auto-refresh was needed. But the way I'm running it as a slide show, the page will be reloaded every 45 seconds, so there is no need for it to auto-update. Good thing too, because this memory profiler is kicking my butt.