Keeping Memory Leaks in Mind to Program Better.
In this article, I concisely explain the notion of memory leaks in computer science and how by simply understanding memory leaks will help you code your application more efficiently. As many others, I often heard the term “memory leak” through my travels as a beginner programmer but I never fully understood what they are and what to do about them. Thus, this blog is aimed towards beginner programmers or programming students such as myself to increase knowledge on this subject.
What are Memory Leaks?
Firstly, what’s a memory leak? As programmers, we know that the code we write takes up memory. Anytime objects or variables are created memory space is required each time the program is executed. Essentially, a memory leak is when memory is allocated for something but is no longer needed and now occupying RAM needlessly. One way to think of this if you turn on the faucet and the water is running but when you are done with whatever you needed the water for, you simply turn it off. The memory leak would be if the faucet still had some water dripping out when you didn’t want it to.
Mainly, memory leaks are a major issue because they lead to diminished performance. If a memory leak is occurring consistently and a program is using more memory that is required, then it will eventually take up all available memory. Hence, performance will be continuously slowed down until the application crashes or until the program is closed completely.
Memory leaks are extant usually due to poor programming or unintentionally written code. For instance, you may have created an object and no longer have a need for it but your app may still think you do, thus it will still hold memory for it. Unfortunately, since memory leaks are the result of bad coding practices, this suggests there’s not much that can be done to prevent them. That’s why it’s important to understand the concept of memory leaks and the fundamental of intentionally writing your code to be more memory efficient.
Garbage Collection and Javascript
It seems different programming languages have their own way of dealing with memory leaks. For lower level languages such as Pascal, C, or C++ the programmers have to explicitly/manually allocate memory and then free up the memory after the program is done executing the code. However, languages like Javascript have automated memory management systems. The automated system solves a great deal of issues since they automatically allocate memory each time an object is created AND when it’s no longer needed it will automatically free that space. The process of automatically releasing unused code is often referred as “garbage collection”. Garbage collectors are highly effective and do a good job of analyzing your code and getting rid of unused variables/objects. This is probably why beginner programers don’t have a sense of coding in a way that is memory efficient since a system is place to do it for them. However, to me it’s even more important that programmers understand memory leaks so they don’t acquire poor programming habits throughout their careers that will be noticed by potential employers. Additionally, garbage collectors aren’t perfect, they are just algorithms. They don’t know what you are intentionally writing or not. And there are still many ways garbage collection doesn’t fully solve memory leaks.
For instance, undeclared global variables will not be considered as “garbage” by the garbage collector since it doesn’t know what you are going to do with it. A global object will be holding space in memory every-time a script is ran since the program believes you are going to use this variable for something. Highlighting that it’s important to understand the scope of the objects we create and being diligent about when to create them.
Memory Leak Examples in React.js
One of the primary reasons for memory leaks in React applications is unreleased listeners in componentDidMount. Here is an example depicted by Magiera in his 2018 blog:
There are keyboard event listeners in the code above that keep track of the keyboard status as state of the component. The event listeners get mounted with componentDidMount, however the listeners are still in effect once the component gets unmounted due to rendering logic. Even though you are not rendering the component, the event listeners are still firing off in the background. Mageria explains: “At the same time, Keyboard module has to keep the list of active listeners in global scope — in our case, it will retain the arrow functions we pass to addListener method. In turn, these arrow functions retain this – i.e., the reference to the Composer component, which in turn references its properties via this.props, its children via this.props.children, its children’s children, etc. This simple mistake can lead to very large areas of memory left retained by accident.” To solve this, you will need to remove the event listeners using componentWillUnmount:
Mageria’s blog does a great job of explaining this in detail and gives even more examples of memory leak problems for React Native and React.js in general.
Another example of poor memory management in React.js is admittedly from my own self. Where I had a clickHandler in a parent component passed down to the child component which was just passing back up a movie object as props. However, the clickHandler just needed the id of the movie object to make a POST request and I was passing up an ENTIRE object when only an integer of the movie.id was needed. Thus, any time the browser listened for this click event, an entire object filled with a ton of information was passed around, instead of simply the id that the object had as its key.
Looking back at a lot of my code after briefly understanding memory leaks helped me see a lot of my mistakes. Additionally, I felt that I learned something that will help me become a better programmer and it seared into my brain that I should be writing my code more attentively.
In conclusion
In this article, I spent a lot of time complaining about memory leaks and how important it is to avoid them. Truth be told, it’s nearly impossible to avoid memory leaks. As programmers we have a lot of things to keep track and constantly be mindful of. So adding the pains of making sure every single line of code you write should account for memory leaks wasn’t the aim of this blog. We need to simply be aware of memory leaks and should be programming more intently. Employers will likely be more inclined to seek out candidates that are cognizant of their code and can explain the decisions that hey make. You may find yourself in a position where certain code takes up a lot of memory or a seemingly unnecessary amount. However, if you can justify your methodology then it should be no issue, but in order to explain what and why you are doing certain actions, you need to acquire some knowledge to showcase that confidently. Keeping memory leakage in mind definitely helped me write better code. I realized in my past projects how poorly I have written code and didn’t consider the strain certain actions would have on a user’s browser. Even though I am brand new and still learning, I feel just learning a little bit more about memory leakage increases my appeal to potential employers looking for software engineers.
