4 ms·

Memory leaks: the forgotten side of web performance

89 points by homarp 5y ago

hereforphone 5y ago
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.
- nmaludy 5y ago
  Warning, im feeling synical this evening... Completely agree! I find that a lot of developers don't understand how things work under the hood or how things fit together. This always comes back to bit them. Same can be said for modern infrastructure engineers / DevOps / sysadmins.
  - democracy 5y ago
    fwiw we operate on layers and layers of someone else's code, that's not possible to understand how each dependency works, what's its performance, etc. And also do it for each new update of such libraries. Unless you develop in some very closed environment maybe, but for a modern java/js project that's not possible. The reasonable approach is to load test the mostly used workflows, optimise if necessary - anything else would be fixing imaginary issues, working on non-existing problems, etc - there is normally no time or money for it.
- NeutralForest 5y ago
  I agree with the sentiment but at the same time, there is so much to learn now. Especially w.r.t the web, there are so many layers of abstractions and frameworks, you might even do "things right" on your end but have memory leaks hidden under all that abstraction. At the same time, writing everything yourself isn't possible because of time/money/life constraints. I also think the web is terribly bloated though.
fabiospampinato 5y ago
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.
- adzm 5y ago
  node has the command line option --nostring_slices to disable this behavior fwiw.
- deleted 5y ago
  [deleted]
- nolanl 5y ago
  That's really interesting. I wonder if this is a Chromium-only issue? It may be worth filing a bug: https://bugs.chromium.org https://bugs.chromium.org I'm not an expert in this space, but it seems to me that the JavaScript engine could eventually clean up that memory, maybe based on some heuristics (e.g. the size of the original string, whether any references to the original string exist, etc.).
  - nosianu 5y ago
    https://bugs.chromium.org/p/v8/issues/detail?id=2869 https://bugs.chromium.org/p/v8/issues/detail?id=2869 "Issue 2869: Substring of huge string retains huge string in memory" Status: Assigned (Open) Reported 2013
FpUser 5y ago
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.
- not2b 5y ago
  Yes, I've repeatedly encountered programmers who insist that leaks aren't possible in GC languages, and they then build ugly stuff where nothing ever gets freed because a tangle of references connects everything to everything, and they won't even call this situation a leak, even though they have allocated objects that will never be used again that keep growing.
  - howinteresting 5y ago
    Yeah, GC inevitably leads to hideous memory leaks. In some cases that's totally fine! For example, if you have a stateless fleet of server-side applications and you can restart any of them at any time, or if you have a CLI that runs for short amounts of time. In other cases, for example long-running stateful servers, games or GUI apps, it can quickly become a real problem.
lewisl9029 5y ago
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 https://www.youtube.com/watch?v=YDU_3WdfkxA
Matheus28 5y ago
>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
- nolanl 5y ago
  It depends. For elements that are removed from the DOM, then yes, the event listener should also be automatically removed: https://jakearchibald.com/2020/events-and-gc/ https://jakearchibald.com/2020/events-and-gc/ However, if you're adding event listeners to the document, the window, or some permanent element (header, footer, etc.), then those won't be GC'ed since the DOM node is never GC'ed.
robocat 5y ago
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.
magicalhippo 5y ago
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.
deleted 5y ago
[deleted]
kohlerm 5y ago
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).

89 points by homarp 5y ago

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.

nmaludy 5y ago
Warning, im feeling synical this evening... Completely agree! I find that a lot of developers don't understand how things work under the hood or how things fit together. This always comes back to bit them. Same can be said for modern infrastructure engineers / DevOps / sysadmins.
- democracy 5y ago
  fwiw we operate on layers and layers of someone else's code, that's not possible to understand how each dependency works, what's its performance, etc. And also do it for each new update of such libraries. Unless you develop in some very closed environment maybe, but for a modern java/js project that's not possible. The reasonable approach is to load test the mostly used workflows, optimise if necessary - anything else would be fixing imaginary issues, working on non-existing problems, etc - there is normally no time or money for it.
NeutralForest 5y ago
I agree with the sentiment but at the same time, there is so much to learn now. Especially w.r.t the web, there are so many layers of abstractions and frameworks, you might even do "things right" on your end but have memory leaks hidden under all that abstraction. At the same time, writing everything yourself isn't possible because of time/money/life constraints. I also think the web is terribly bloated though.

fabiospampinato 5y ago

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.

adzm 5y ago
node has the command line option --nostring_slices to disable this behavior fwiw.
deleted 5y ago
[deleted]
nolanl 5y ago
That's really interesting. I wonder if this is a Chromium-only issue? It may be worth filing a bug: https://bugs.chromium.org https://bugs.chromium.org I'm not an expert in this space, but it seems to me that the JavaScript engine could eventually clean up that memory, maybe based on some heuristics (e.g. the size of the original string, whether any references to the original string exist, etc.).
- nosianu 5y ago
  https://bugs.chromium.org/p/v8/issues/detail?id=2869 https://bugs.chromium.org/p/v8/issues/detail?id=2869 "Issue 2869: Substring of huge string retains huge string in memory" Status: Assigned (Open) Reported 2013

FpUser 5y ago

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.

not2b 5y ago
Yes, I've repeatedly encountered programmers who insist that leaks aren't possible in GC languages, and they then build ugly stuff where nothing ever gets freed because a tangle of references connects everything to everything, and they won't even call this situation a leak, even though they have allocated objects that will never be used again that keep growing.
- howinteresting 5y ago
  Yeah, GC inevitably leads to hideous memory leaks. In some cases that's totally fine! For example, if you have a stateless fleet of server-side applications and you can restart any of them at any time, or if you have a CLI that runs for short amounts of time. In other cases, for example long-running stateful servers, games or GUI apps, it can quickly become a real problem.

lewisl9029 5y ago

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 https://www.youtube.com/watch?v=YDU_3WdfkxA

Matheus28 5y ago

>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

nolanl 5y ago
It depends. For elements that are removed from the DOM, then yes, the event listener should also be automatically removed: https://jakearchibald.com/2020/events-and-gc/ https://jakearchibald.com/2020/events-and-gc/ However, if you're adding event listeners to the document, the window, or some permanent element (header, footer, etc.), then those won't be GC'ed since the DOM node is never GC'ed.

robocat 5y ago

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.

magicalhippo 5y ago

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.

deleted 5y ago

[deleted]

kohlerm 5y ago

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).