Memory leaks: the forgotten side of web performance

I've been looking into memory leaks for an Electron app recently, and a major source of problems are strings, strings have sort of this hidden feature/bug: if you slice a string a new string is not allocated in memory, instead the original string is kept in memory and a couple of numbers indicating the start and the end of the slice as indexes in the parent string are kept in memory. It sounds alright, good for memory usage even, but in many cases you'll be consuming way too much memory because of this.

Example: you split a string into words for spell-checking purposes, once you've spell-checked each word you cache it so that you don't have to ask the spell-checker again if it's valid or not, now each time the original string is edited every single intermediate string produced during the edit could be kept in memory just because you are caching a word out of each of them. This can get out of hand super quickly.

Each time you are extracting a string out of another string this problem can arise.

I have found that closures are one of the unobvious ways to leak memory. On some browsers it was necessary to set values to null at the end of the function, otherwise variables captured by the function closure would not get garbage collected.

If you suspect a leak with an array or object, one thing that helped me in the past was to create a unique element, and put that on a array or object. The tools for seeing rogue loose elements are easier to follow than the tools to detect where a leak is coming from - changes are easy to find with before and after diffs. If the element doesn’t get garbage collected, then the array or object still has a reference.

E.g.

  function someFunction() {
    xxyArray = [];
    xxyArray.__leakdetect = document.createElement(‘LEAKDETECTxxyArray’);
    someObject = {};
    someObject.__leakdetect = document.createElement(‘LEAKDETECTsomeObject’);
    // do stuff with xxyArray and someObject
  }

Edit: Only do that when debugging, since elements are big and slow. Note that you don’t insert the element into the page DOM. For DOM “component” objects with a lifecycle (SPA app built using a component framework), I added a LEAKDETECT element into the page itself as part of the component constructor, and removed it from the page when the component destructor was called.

This is coming from the perspective a person who is not a web programmer, but who has done lower-level programming. Memory leaks and other things (security issues included) are going to naturally come from focusing the education entirely on upper stack subjects. One must understand the complete machine in order to actually make things solid. The complexity is making that increasingly difficult to do these days unfortunately.

To anyone looking to learn how to use browser devtools to identify memory leaks, this HTTP 203 episode is the most approachable resource I know of:

https://www.youtube.com/watch?v=YDU_3WdfkxA

>You called addEventListener but forgot to call removeEventListener.

Shouldn't this be handled by the browser gc? If the element isn't in the DOM and there aren't any js references left anymore

Slack on Firefox leaks like hell for me. I've had to get an extension that reloads the Slack page once an hour. Otherwise it gobbles up several GB of memory before crashing the process.

Reddit behaves similarly, with its endless scrolling pages and whatnot. Invariably during a heavy Reddit session my browser will run out of memory. On Linux this is extra infuriating as the system will become unresponsive while it tries to swap first.

This is one of the reason I dislike GC. By enabling seemingly care-free usage as well as making it hard to reason about when resources are released, it's easy to dismiss thinking about it at all.

The irony is that people used to complain that JVM applications are memory hogs, but there's still the trend to use JS Web based Frameworks(Electron etc) for Desktop applications. For the JVM memory leaks and high memory usage are a problems which are mostly solved thanks to the Eclipse Memory Analyzer tool(MAT). IIRC we(at SAP) reduced the amount of JVM issues 10x or so after introducing MAT(before it was open sourced).

Whoever came up with this GC will save you from memory management headaches mantra deserves to be quartered. What is even worse is that thanks to a modern programming education however it is done most developers believe in this BS as well.

Sure GC will save one's ass in trivial cases, but few non-trivial become way more difficult to discover.