I'm fairly new to browser's memory management, and memory leaks.
I am making a web app using Angular.js which uses web services to get Model.
Plus, all controllers are linked to templates with ngRoutes except one. It is the controller of my app's main menu which also provide additional logic to router. I inject into each controller this MenuController.
One part of my app needs to check often if there are new informations, to make report. I implemented this as a function based on a $timeout which fires himself inside the function.
I have some trouble cause I found out that my app has some memory leaks and makes crash the browser after 5-6 hours of non refresh. I can see it in Chrome and Firefox but I don't know how to solve this issue.
Which steps should I go forward ?
Thanks.
For memory leak in Angular, I would recommend reading this article.
Also check the way you are using ng-repeat (if you do so) in your app… this is a common source of leak when you don't use the 'track by' syntax.
Related
Whenever I switch routes, I have noticed that Vue components in my application are never destroyed and only created (the # Deleted column is always 0 as I toggle between routes). To be extra clear, the number of new components created is always equal to the number of components displayed on that route i.e. NONE of the Vue components are ever destroyed and every component on the route is recreated when a route is revisited.
I've been researching to debug the problem and I know that the following are usually culprits of memory leaks in VueJS.
The use of a Global Event Bus and failure to unregister the callback. This is detailed clearly here. While I do use a Global Event Bus in some areas of my application, I'm also experiencing memory leaks on pages where I don't create any event listeners on the Global Event Bus, which leads me to believe that this is not the issue here.
Failure to manually clean up memory yourself when using 3rd party libraries, a problem outlined by the VueJS documentation. Again, I've been looking at memory usage on pages that do not use third party libraries and I'm still getting memory leaks on those.
There is one more potential issue I've come across which I don't quite understand. In this github thread, the OP said the following in regards to potential causes of memory leaks in VueJS:
So I made sure I wasn't doing anything stupid like storing a reference
to this on a Vuex Store...
Can someone please explain what the OP means here in regards to Vuex and memory leaks?
Additionally, what are some other potential issues that cause memory leaks in VueJS that I have missed that could be affecting my application?
How else should I be debugging my memory leak outside of using the Memory tab in Chrome devtools?
Memory is such a pain to debug and your logs look curiously similar to mine.
What i found was be careful of your logs :
console.log(vuecompoent) actually stores your component in memory and does not release it.
Also consider that I turned off vue dev tools as well, but im not sure if this was causing the issue .
Look into the retainers section . This may give you some insight.
Today I have a job interview and they asked me a different question. He said in the Single Page Application (SPA) structure the front-end developers should manage the client resources and cleaning up the other process usages (RAM, CPU).
He said when the clients open more pages or send more requests, the client RAM and CPU will use more and in the future theirs browser will crash or this browser will be slowly because the resource usage is more and more and the components will open on each other.
He said there are many methods to handle this problem, and every body have a different solution for solving this problem. I told him I think the Virtual DOM can solve this problem and by default the ReactJS can support this problem.
He approved but I have doubts who my answer was correct. So, is a right method or solution to manage the SPA clients computer resource's (RAM, CPU)?
The browser (client) does not give you the ability to directly access system resources like RAM or CPU hence you can't really control these resources. But traversing the DOM too much and making too many frequent API calls can lead to a less performant web app. React does improve rendering through its virtual dom feature which means the DOM only gets updated when it absolutely needs to. Also caching less changing datasets can reduce the number of API calls you web app has to make. In general try not to render huge data in a single page for data-heavy web apps, always use pagination. also, try not to fetch large data in one API call too.
we have built our service dailymus.es to be mobile friendly, but we are hitting on a range of performance issues when accessing it on the mobile phone.
Specifically, it crashes after a few "pages" and when we have a lot of content on the page.
I am suspecting that we have too many event handlers and/or memory leaks. What methods do you use to eliminate these problems with Backbone?
I suggest you test your site using Google Chrome's Developers Console. Use the Profile tab to examine the state of the heap.
Most leaks of backbone models/views are due to not detaching the DOM events from views and the binding (on) events from models.
Make sure to override the remove method of your backbone view and make sure you .off() from everything you set to .on(). Don't forget to call remove on sub-views.
To find leaks:
Take a snapshot
Run your code to create a view and then remove it
Take another snapshot
Compare the snapshots to find the new objects created who weren't released.
More about the Google Chrome Heap Profiler
Backbone wastes a lot of memory which is the hardest thing for mobile. There's a lot of techniques for object pooling on the DOM elements, updating elements instead of recreating templates, limit loading images until the last minute, holding any updates until right before the paint cycle.
Mobile web can be performant if the memory is managed properly. PrefView is a good example and can get 50FPS on long scroll list on an iPad mini. https://github.com/puppybits/BackboneJS-PerfView
What I'm trying to do is build a simple app in PhoneGap and Backbone.js. The app has a login page which, on a successful login, sends the user to a simple menu with a few options. The user has the option to view their saved lists, view a list of items or view an info page. I know how I want to structure all of the Views and Models so the question I have is whether or not doing this all on one page has any downsides when compared to using multiple pages.
To break it down into smaller parts:
Does loading all the javascript in the one page have serious performance implications?
If the router closes, .remove() and .unbind(), all the current view when switching to a new view, do I still risk memory issues?
Backbone was designed to be built for SPA applications. Im not saying that you can't span Backbone over multiple pages, but in my opinion that adds more complexity. From your description, I would keep your application as an SPA.
Secondly, build your application using modules. Use a library such as require.js. I could not recommend it enough. I wont go into too much detail about why you should use it, because you can read more about it here (I would recommend reading the entire book). Once your application is ready for deployment, you can use r.js, require.js's build script. This will concatenate all or some of your modules into a single file. This will drastically speed up the performance of your app especially if you have a bunch of modules.
Finally with regards to memory optimization, I use a method developed by Derick Bailey which you can read up about here.
Hope this helps.
As I understand it the "conventional" way to handle page reloads is to duplicate functionality and presentation on the web stack using its controllers, views, and models. I'd appreciate insight on other (possibly better) ways to handle these situations. As well as feedback on the following two approaches:
Reload the js framework based app/suite on every web (stack) app page thus
forcing the js framework to handle all routing and rendering
Use the web stack to route interactions and then use backbone to
display views depending on the interactions.
Thanks!
IMHO the 2. approach is the one Backbone has born to :)
Following this approach we'll finish with what is called Single Page Application.
But to achieve this in medium-large applications can be very exhausting. You have to deal with complicate Router that has to be in charge of initialize or replacing elements, also you have to take care with memory leaks and ghost Views. You have to define a system to refresh your Collections and Models due you are reusing them in every page, ...
So a combination of both approaches can be also a good idea. You can split your application in modules like: ManagingUsers, ManagingPosts, ManagingMedia, create Single Page applications for these modules, containing index, edit, show, ... actions that don't reload the page, and if you move to another module the page will be reloaded and in company of the whole framework and with a healthy memory reset.