angular.js performance issues

Question

Batarang on the performance tab shows that on the app\'s root, angular is calling function that looks like that: function (a){var e,f,i=a.$eval(h),m=hc(i,.

Answer 1

So I stumbled across this months after the question was asked when I was having what I think is a similar problem. Let me describe my issue and my solution (that does not involve a directive) and you can see if it applies to yours.

I was building a table. First I'd request the info telling me what rows were in the table, then I'd request more info that fills in the cells of the table. So I'd get the first request and add all the rows to the table, then request the cell data. I'd fetch the cell data by row, but in a large table this would still be a lot of requests. When I got the cell data back for that row, I'd fill it in.

This made for a really cool effect, all the cells with spinning icons waiting for data. BUT, it made it really slow. In Chrome, that was fine, the browser would slow down some, but it would continue to work. But in FF, it would get that annoying "script busy or not responding" messsage. If you clicked Continue it would work fine, but if you clicked "Cancel" you'd stop the script and nothing would work.

So, here's the solution I came up with. No directive required. All I did was build the data for each row completely, and only then add the row to the variable used by the ng-repeat. This way it is MUCH faster. The rows fill in as it gets all the data back, the $watch's are still there, but you are not triggering a ton of them at once and you can still have them to be able to change the data later (in my table you can edit each cell of the table so being able to change the data easily later was important).

Hope this helps someone.

Answer 2

Something to consider when building an Angular application where you're dynamically expanding the contents of an ngRepeat. Every ngRepeat you set up, sets up a watch. Every {{binding}} or ngModel you do inside of that repeat, sets up another watch, and so on. Each of those creates function and object instances, and also needs to be processed on every $digest. So, if your running into performance issues, you may need to implement a custom directive that writes out your data without setting up those superfluous watches, so you're a little more performant. That my 2 cents.