3 ms·

Everytime I read an Angular postmortem I'm intrigued that I never see memory issues being raised. In a recent rewrite of one of our applications into Angular w

by onehp 13y ago

Everytime I read an Angular postmortem I'm intrigued that I never see memory issues being raised. In a recent rewrite of one of our applications into Angular we had huge issues with it consuming memory. I think our use case is quite distinct, we have a telephony component that needs to stay loaded so single page app really does mean single page app for us, but even so I would expect to see memory mentioned every now and then.

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.
joelhooks 13y ago
our app is... big. It runs great on "modern" devices and browsers, and we haven't had any severe memory issues. We profile on a semi-regular basis.
- onehp 13y ago
  I can't show you our app as it's internal but in my travels I found the Dairy Queen site exhibits similar behaviour. https://www.dqcakes.com/#/home https://www.dqcakes.com/#/home Get through to where you pick your cake design and pick one, then go back, repeat and watch the memory increase.

by onehp 13y ago

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.

joelhooks 13y ago

our app is... big. It runs great on "modern" devices and browsers, and we haven't had any severe memory issues. We profile on a semi-regular basis.

onehp 13y ago
I can't show you our app as it's internal but in my travels I found the Dairy Queen site exhibits similar behaviour. https://www.dqcakes.com/#/home https://www.dqcakes.com/#/home Get through to where you pick your cake design and pick one, then go back, repeat and watch the memory increase.