

Managing Memory in Javascript is Hard - superfreek
http://polarmobile.com/blog/2013/5/managing-memory-in-javascript-is-hard

======
davidw
And to confuse things further, we'll provide examples in Coffeescript?

To be fair, they do link to some JS conversion thing, but I'd prefer to read
the examples right in the article - "don't make me think" and all that.

~~~
mAritz
Yeah, especially because Coffeescript can be very liberal with creating
objects if you don't know exactly what you (and coffeescript) are doing.

edit: Disclaimer: I have written and am still occasionally writing canvas
rendering stuff in coffeescript and after some meddling around with some
annoying bits it has been quite pleasant. For example you should make sure
that functions that don't need to return anything, return false or null or
undefined. Otherwise coffeescript will return whatever your last statement
evaluates to. This is especially bad if the last thing is a loop.

~~~
Zr40
CoffeeScript doesn't actually create any objects you're not telling it to do
so. It does return the value of the final expression, but you placed that
expression there to be executed. Its value will be returned and that might
cause it to remain reachable for some additional time, but the value was
created by your expression, not by CoffeeScript's return semantics.

------
georgemcbay
I still have nightmares about memory management in JavaScript following an
unfortunate project involving a very media-rich application running on Vizio
TVs with "Yahoo Widgets for Connected TVs" (a non-HTML JavaScript app
framework that derives from the old Konfabulator).

Not only do you have all the usual issues with JavaScript and memory, but the
amount of RAM available is tiny and the garbage collector is run on a set
timer and if you blow your memory budget between these timed calls to the
garbage collector, the program soft crashes (you'd think an emergency gc would
be scheduled if memory pressure were that high -- you'd be wrong!). Even if
you were very careful to set unused objects to undefined or explicitly delete
them, the memory those objects took still counted against you because of the
timed gc system. Object pooling was absolutely required but even then you had
to be very careful not to blow your memory budget.

The 'soft crash' would result in a situation where the app and overall runtime
is still running but the state of the software is no longer reliable until you
_reboot the TV_. And none of this stuff (the timed gc, etc) was documented at
all, and there's little to no active community for "Yahoo Widgets" so you
basically had to figure this all out on your own.

------
dalore
Managing memory in ECMAscript is hard.

These are the same problems from Actionscript (I know the crowd here has no
love for AS though).

------
joubert
Most folks probably write JavaScript for the browser.

Not only should you consider using object pooling for JS objects (like the
author describes), but you also want to think about DOM element pooling,
especially when you are dealing with large lists.

~~~
dspillett
DOM element reference cacheing (and pooling) can significantly improve the
responsiveness of very busy browser UI code (particularly in loops that make
many DOM queries and/or updates) and can make the code more readable too, but
be careful as you can create memory leaks especially in "classic" IE. Such
leaks only tend to last as long as until the user navigates away, but they can
become significant for single-page applications.

~~~
ryanpetrich
In many cases they can exist until the iexplore browser process terminates.

------
alfredp
I would love to know if using emscripten will make memory usage more
deterministic.

------
maas
why is Jay Kay from Jamiroquai teaching memory management?

