data.splits in treeLookup leaks memory

[SLaks]

data.splits in treeLookup leaks memory

[lefnire]

woo, subscribing - there's definitely a memory leak somewhere (HabitRPG/habitica#165), this could be the cause.

[nateps]

This was a quick fix to speed up the model when there are a lot of queries and refs. Cloning the array is actually much faster than doing split on my profiling. True that the cache should get cleaned up, but this is only a client-side problem, since it is only in the model. This is definitely not related to any server-side memory leak unless a model is being kept around on the server (which shouldn't be done)

[lefnire]

I'm hunting Habit's memory leak (which is substantial - fills up 5GB in ~2h of 100-200 concurrent users). Still unsure the root, but I'm using node-webkit-agent to take cross-page-load heap snapshots. This showed up as the primary difference between a single refresh:

Says splits. Next is ids in the View object. (Man, too bad I can't share this interactive session with y'all somehow...) Anyway, this is a server memory heap dump, not client - and it looks like data.splits is causing a >1MB leak with a single page refresh.

[SLaks]

Are those arrays sticking around beyond their page loads?

If so, that's causing your problem. See if you can find out what is referencing the model after the page is rendered; this could be a bug in Racer or a usage issue in your code.

[lefnire]

Got it - hunt to find any persistent server-side references to model

[SLaks]

This was fixed by 920784f