Memory leak when using infinite loops

[bob2517]

There's a memory leak due to some passing of object references related to after/every and possibliy elsewhere. It's noticeable when after and every are used in recursive loops, as I recently spotted when writing a screen saver. It's solvable by passing pointers instead of the objects themselves and switching to manual garbage collecting. And by removing bindings on those timeouts.

Probably should do this everywhere - stop passing object references and have manual clean-up so that everything stays under control.

[bob2517]

Note to self: Never assume you know where memory leaks are. Always use DevTools and look at where the leak is, otherwise you're coding blind and may not spot the main culprits.

[bob2517]

Good news is that I'm not getting any size increase through the use of the screen saver now after some changes. I need to leave it on for a while and then come back later. Fingers crossed that the worst of what I was running into was over, though I have a fallback plan if these things keep appearing. The problem is based on object references at a JS engine clean-up level. I use these a lot in the core out of ease of use. But I don't particularly have to - very early versions of ACSS didn't have object references. It just made the code a bit prettier and more succinct and made some things a bit quicker to code. Anyways, if I'm not happy by progress on this by this time next week I'm going to remove the problem by removing the objects altogether so that manual garbage collecting is the order of the day.

[bob2517]

Changed the title of this issue to make this less alarming (to myself at least). No memory leaks, as far as I know, for regular use or for SPAs. It's just when you have "while true" loops or keep looping over the same routing with pauses and triggers. Unfortunately I ran into this whilst building a screensaver recently. I switched to doing just the screensaver in native JS to get around the issue by using a couple of nested settimeouts in a function. The rest of the app is a quite complex SPA in ACSS and works fine with no memory leaks.

In terms of debugging, I now don't have any noticeable memory increase now over looping for long periods, which is great, but a bit weird. It's more like there seems to be a chain of references that keeps increasing and slowing things up that I haven't spotted exactly where yet. It's affecting the speed of events. It's probably going to be a face-palm moment, or something really stupid that I haven't spotted, when I do actually spot the problem.

[bob2517]

Resetting on fixes for this for the moment. Will do a more targeted fix a bit later on. Moving onto other fixes.

[bob2517]

Thinking about just having a trigger option of "clear-memory", which would start a chain of events off without reference to anything earlier. That would probably solve the problem without the necessity to rewrite the entire core.

Will look at this after 2.10.0 release.

[bob2517]

New trigger-fresh command solves the memory leak. Use this instead of the regular trigger command. Trigger stays in the event flow, as do loops, and those shouldn't change behaviour, but trigger-fresh does a settimeout which puts it outside the event flow and performs a fresh call with no inherency of variables.

I'm considering this bug fixed. Docs need to explain the situation. Infinite loops should be discouraged, and trigger-fresh should instead be used as the solution.

[bob2517]

Closing pending release.