It’s a hack. If Chromium+v8 would just support displayName, it could all be nice and clean and part of SproutCore (please go tell the Chromium folks how helpful this would be).
As it is, this hack could have some SEVERE side-effects, but chances are, if you are trying to debug a memory leak, you won’t care about these side-effects because everything else will be driving you MAD (and, you’ll probably be able to find these side-effects much more easily than the leak itself).
It is very simple; here is how to do it for ListItemView:
SC.mixin(SC.ListItemView, { create: function() { return new SC._ListItemView(this, arguments); } }); SC._ListItemView = function(base_type, args){ base_type.call(this, args); }; // for extra safety (should get around most potential side-effects): SC.mixin(SC._ListItemView, SC.ListItemView); SC._ListItemView.prototype = SC.ListItemView.prototype;
Now, ListItemViews will show up as SC._ListItemView in the heap profile. Hooray!
P.S. This revealed for me that the objects leaking were not SC.ListItemViews. I still have no idea what is leaking, and am giving up for now—but at least I’ll have better tools when I come back to it. :)
Tags: chromium, google chrome, memory leaks, profiler
Did you find the ListItemViews were not leaking before or after you apply the fixes you’ve already submitted to the master branch? I am really surprised to hear this.
Oops… apparently this was in my spam queue, so I didn’t find it until now… weird.
I found they were not leaking after the fixes I submitted to the Observables branch (specifically, my observables branch; not the main one). Before then, the ListItemViews were leaking quite a lot.
Now the leaks are… something else, but I still can’t tell what. What would be really great is if Google (or Apple, in Safari) could make the profiler have all of the features Instruments has—especially tracking individual instances and seeing the stack traces to their creation.