3 ms·

I haven't had significant memory issues with Angular. Have you profiled your app? Where is the large portion of memory being consumed. The apps I'm building

by zenocon 13y ago

I haven't had significant memory issues with Angular. Have you profiled your app? Where is the large portion of memory being consumed. The apps I'm building are being deployed on an embedded system with a custom WebKit -- where the memory constraints are significant (the hardware has a total of about 400MB RAM for everything) -- so I'm pretty conscious about memory issues, and we did test/profile Angular on this hardware and did not find issues. That isn't to say you still can't shoot yourself in the foot with Angular (especially with something like ng-repeat). There are ways to code an Angular app with an eye on memory / performance, and there are ways to do the opposite, but I don't feel like the framework itself introduces significant overhead.

onehp 13y ago
It seemed it was detached DOM elements that were causing most of the problems. We tried profiling with the Chrome dev tools but found it very difficult to pinpoint where to start looking from the thousands of elements generated every-time we repeated our workflow. In the end we looked at the bottom line memory consumption and experimented until we saw reductions. We found using things like ng-show instead of ui-if, essentially preloading the partials and switching between them instead of reloading everytime, saved us enough memory to make the system viable.
- sgrove 13y ago
  We've had similar problems before (outside of angular), and the lack of visibility and tooling is horrendous. However, at Google I/O they demoed the new object allocation tracker, which seems like a vast, vast improvement. Highly recommended for figuring out where memory is leaking and what code is causing it. Here's the session: https://www.youtube.com/watch?feature=player_embedded&v=x6qe_kVaBpg&t=24m10s https://www.youtube.com/watch?feature=player_embedded&v=... Still pretty primitive, but progress at least.

by zenocon 13y ago

onehp 13y ago

It seemed it was detached DOM elements that were causing most of the problems. We tried profiling with the Chrome dev tools but found it very difficult to pinpoint where to start looking from the thousands of elements generated every-time we repeated our workflow. In the end we looked at the bottom line memory consumption and experimented until we saw reductions. We found using things like ng-show instead of ui-if, essentially preloading the partials and switching between them instead of reloading everytime, saved us enough memory to make the system viable.

sgrove 13y ago
We've had similar problems before (outside of angular), and the lack of visibility and tooling is horrendous. However, at Google I/O they demoed the new object allocation tracker, which seems like a vast, vast improvement. Highly recommended for figuring out where memory is leaking and what code is causing it. Here's the session: https://www.youtube.com/watch?feature=player_embedded&v=x6qe_kVaBpg&t=24m10s https://www.youtube.com/watch?feature=player_embedded&v=... Still pretty primitive, but progress at least.