Are you able to explain to me how you are destroying the old DataTable and then creating a new one when the reload button is pressed. I see the destoryTable function in the order.js file. It is calling dtInstanceTable.DataTable.destroy(true); which destroys the existing table, but what I can't see is how a new table is then created after that.
Could you also confirm that you are using the angularway method of initialisation the table - even although the documentation for Angular-DataTables documentation says:
The "Angular way" is REALLY less efficient than fetching the data with the Ajax/promise solutions. [...] If your DataTable has a lot of rows, I STRONGLY advice you to use the Ajax solutions.
This is proving to be surprisingly difficult to track down!
Quick update - I'm still investigating this. I am fairly sure it comes down to the use of ng-repeat but I'm still looking into the best way of handling this.
Hi Allan,
table build again from directive using in html
datatable="ng" dt-options="watchListCtrl.dtOptions" dt-instance="watchListCtrl.dtInstanceCallback" dt-column-defs="watchListCtrl.dtColumns"
when destroying, html loaded again and build new table
With Angular v1.3, the one time binding can help you improve performance.
If you are using angular-resource, then you must resolve the promise and then set to your $scope in order to use the one time binding.
Been doing a lot more investigation into this and I'm absolutely convinced that the issue is related to the use of ng-repeat rather than simply loading the data using Ajax or similar.
The Angular DataTables library appears to have an issue with externally destroying a DataTable - if you were to then update the data source (which might be happening in your code as it exhibits the same issues as my simple test case) the Angular DataTable library will just create the new table. I've filed a bug for this as I would like to get the authors feedback on the subject.
So it should be possible to avoid the leak by using destroy() without any parameters, and either a fix for the Angular DataTable library, or a change in how your code is constructed.
However, my own suggestion would be to not use ng-repeat. I don't really see any benefit from using it, and it is that construct that the memory leak is stemming from due to its added complexity.
Are you able to consider dropping the use of ng-repeat?
Replies
Are you able to explain to me how you are destroying the old DataTable and then creating a new one when the reload button is pressed. I see the
destoryTablefunction in the order.js file. It is callingdtInstanceTable.DataTable.destroy(true);which destroys the existing table, but what I can't see is how a new table is then created after that.Could you also confirm that you are using the angularway method of initialisation the table - even although the documentation for Angular-DataTables documentation says:
This is proving to be surprisingly difficult to track down!
Thanks,
Allan
Quick update - I'm still investigating this. I am fairly sure it comes down to the use of
ng-repeatbut I'm still looking into the best way of handling this.Allan
Hi Allan,
table build again from directive using in html
datatable="ng" dt-options="watchListCtrl.dtOptions" dt-instance="watchListCtrl.dtInstanceCallback" dt-column-defs="watchListCtrl.dtColumns"
when destroying, html loaded again and build new table
Hi Allan,
i make some enhancement when using the one time binding like said in http://l-lin.github.io/angular-datatables/#/angularWay
With Angular v1.3, the one time binding can help you improve performance.
If you are using angular-resource, then you must resolve the promise and then set to your $scope in order to use the one time binding.
Hi,
Been doing a lot more investigation into this and I'm absolutely convinced that the issue is related to the use of
ng-repeatrather than simply loading the data using Ajax or similar.What I believe to be happening is two fold:
destroy()passing the parametertruewill lead to a leak when usingng-repeat- I've made an example test case here.So it should be possible to avoid the leak by using
destroy()without any parameters, and either a fix for the Angular DataTable library, or a change in how your code is constructed.However, my own suggestion would be to not use
ng-repeat. I don't really see any benefit from using it, and it is that construct that the memory leak is stemming from due to its added complexity.Are you able to consider dropping the use of
ng-repeat?Regards,
Allan
we will evaluate your suggestion about ng-repeat