When an ng-grid is destroyed (from e.g. changing path of ng-include or state when using ui-view), there are a couple of parts of the code where cleanup does not seem to be done properly or completely. This results in leaking memory and DOM which can really build up over time.

Plunker: http://plnkr.co/edit/BkGMBu?p=preview

To see what's happening easily, I've been using Chrome's profiler:

1. Take a heap snapshot of the plunker
2. Show and hide the grid using the checkbox
3. Take a new snapshot
4. Show and hide the grid again
5. Take a new snapshot
6. You can flick the grid on and off a few times here and snapshot just to see the memory going up, for a quick confirmation.
7. Compare snapshot 3 to 2 to see all the leaked data, due to forgotten event handlers, parent watchers and references held in the passed options class. I seem to lose about 1Mb of memory every time this small 5 item grid is recreated.

If it helps, I have started opening Chrome with the flags --js-flags="--noopt --nouse-ic --nocrankshaft" to stop V8's optimisations kicking in, which seems to often result in lots of objects that look leaked but aren't.

In the plunker I have also included fixes - comment out the ng-grid script and uncomment the commented script to test.

I aim to put in a pull request with the fixes shortly.