Aggressive memory leak with the cache

[prasannavl]

Velocity is aggressive about caching, and for each element it is run on, its values are cached in the cache variable with an id tag. But the problem is, this cache is never removed.

So, for single page apps, and apps that remove and add elements dynamically, velocity ends up leaking memory quite aggressively.

There should be a way to delete the cache, atleast manually. I use Velocity with react for high-performance scenarios where react idiomatic way of animation has too much impact. However, I'd like to remove the cache on Component lifecycle methods.

PS: I haven't given the source a thorough read, however, it also concerns me that, if VirtualDOM recycles existing DOM elements, and velocity uses the internal cache of elements, it would end up breaking animation and all kinds of horrible things.

If not an automated strategy, there definitely should be a way to atleast take over manual control of the cache.

[ydaniv]

How about using $.remoteData()?

[prasannavl]

Yup. That's what I'm using, however, I saw that it was never referenced anywhwere else in the source code. And it seems most of the default caches go into "velocity" key. However, is there any other key that velocity uses?

It seems quite fragile. There should be a way to clean up everything related to an element in a more robust way.

[ydaniv]

The 'velocity' key is used to store Velocity related data on the object that's namespaced by the node's id.
If you're using jQuery it should clean it automatically for you.
If not you should remove data for every node you remove from the DOM.

[prasannavl]

@ydaniv - No, I don't use JQuery. And yes, that's what I'm trying to do. The problem is that there's no way to actually identify a cache node correctly, outside of Velocity. The cache id seems to be referred in by "velocity" + (new Date().getTime()); - No way to retrive without looping through every object in the DOM node, or by reading the private variable of $.expando.

[prasannavl]

removeData seems to handle all the internal details, and remove keys, if the "key" is known. But it never cleans up the cache itself. (i.e, the entire store).

I am also curious as to why the cache isn't a part of the DOM node itself. It already uses a property inside the DOM node to reference back to the cache, but why not have the cache directly in the node. It should simply it, and gets automatically de-referenced when removed.

[Rycochet]

I've been making extensive use of in-element data for a work project, and it might be worthwhile considering getting away from the jQuery.data side of it and storing the cache in our own magic ID instead - would certainly fix this issue, and might be worth doing - needs discussion before anything is done though.

[Rycochet]

In Velocity 2 the per-Element data is stored in a WeakMap, so it will be freed when the Element is removed from the DOM and released. THe list of animations is also no longer a list so frees each one as they finish.

[Rycochet]

Changed to storing the data against the element itself, without any internal references (was slightly faster and made it easier to manage).