Memory leaks

We know what happens when our programs leak memory over time. User interactions start to slow down first the current page and later the entire browser, especially when all currently open tabs operate on the same memory. Never-ending loops can crash the browser, but also the additions of more and more objects that take memory, but never get garbage collected. Profiling allowed us to see which parts of the code required the longest execution time, but it didn't say anything about how memory was allocated during that execution time. We were left to guess how parts of our code actually behaved. What could have been useful is to see: ok, that variable took so much memory, that function so much and so on. Something similar to what Xdebug does for PHP. This explains why it's always a good idea to write programs that do their work with the least amount of variables, functions, and (for languages that support it) classes. We often tend to create too many convenience variables that take additional memory or slow us down, while we try to mentally calculate our way through the code. But when used right, these variables can improve the readability and maintenance of our code.

Not knowing the memory requirements of our apps is the same as not knowing processor requirements. The last was a reason why Rasmus Lerdorf was excited speaking about HipHop. Disk space is another thing to consider and it's probably not enough to just announce the download size, but also the install size of the product in fully usable state, which will be the end goal of the user seeking value. The increasing computational power of modern PCs isn't an excuse to not publish system requirements, even when many app creators don't do it anymore. If developers think that they aren't constrained in any way, they'll write less efficient code and as a result, when they are faced with a mobile device with slower hardware, they'll crash it every time. System requirements are part of the documentation of a program that allows users to gauge the efficiency of our work. By not providing them, user's won't know what to expect or won't trust us, which is even worse. What we don't know can easily become what our users don't know.

Getting details about JavaScript memory usage wasn't easy so far, which is why I think that recent advancements in Chrome (and more specifically taking heap snapshots in the "Profile" tab in the developer tools) can give us the knowledge we need to write more stable applications. Addy Osmani has written a great article about how we can use these features to find memory leaks in our code. Right now, we are presented with a lot of data that isn't necessarily easy to understand, but at least we can start to see the contours. I was also slightly surprised that the installed browser extensions can also manipulate the data, which is why it is preferable to test within an incognito window (Ctrl+Shift+N). Memory leaks can be a serious obstacle for creating better user experiences and it's great that we finally have a tool that shows up what we didn't know.