Memory leak? about jump.js HOT 6 CLOSED

would you mind digging into this a bit further for me? I think the spike may be caused by requestAnimationFrame being called 60 times per second, to achieve a 60fps scroll. The scroll completing would explain the "cliff". In that case, I wouldn't think it's a memory leak. I know the Chrome dev tools allow you to dig into the JS stack and see what function(s) are being called, perhaps your tools provide a similar feature?

will leave this open until I hear back, thank you

from jump.js.

It could be as you say - I just went to your test site... hit record, pressed the go down button, pressed to go up button.

I havn't had chance to dig into it yet though, could it be creating variables every time rAF calls?

from jump.js.

the _loop function is what runs within each requestAnimationFrame call. that code is highlighted here: https://github.com/callmecavs/jump.js/blob/master/src/jump.js#L18-L31

it's only referencing and working with existing class properties - all that is created is more requestAnimationFrames. therefore, I don't think this is related to creating variables. there is some math related to the easing function that happens in each loop, but I couldn't imagine those low level operations would cause this type of spike.

if you get a chance, i'd really appreciate you doing some more digging 🙌

from jump.js.

did some profiling in the Chrome dev tools, and I'm not seeing anything out of the ordinary. going to close this for now, as I believe what you're seeing is related to the requestAnimationFrame calls. if in your futher testing you come across something in particular, I'll reopen it and take a peak. thanks again for your efforts

from jump.js.

here are some screenshots of the heap from the Chrome devtools as well:

seems as though everything from the lib is insignificantly small

from jump.js.

looping in @jaxgeller, as he helped with some of this profiling

from jump.js.