Ask HN: Why aren't there any tools that detect memory leaks in JavaScript (web)?
Why is it that Javascript (in the browser) doesn't have any tools that would allow developers to perform memory leaks detection? Chrome has a heap profiler that can take memory snapshots, but it feels nothing like tools like Valgrind.
6 comments
Chrome devtools comes with memory analysis tools. https://developer.chrome.com/docs/devtools/memory-problems/a...
Some of these (heap dumps) can also be used with nodejs. That being said, from my experience most UI developers do not care much about memory leaks,most likely because the assumption is that a page is not long running enough that's it would matter.
Some of these (heap dumps) can also be used with nodejs. That being said, from my experience most UI developers do not care much about memory leaks,most likely because the assumption is that a page is not long running enough that's it would matter.
Unlike C, JavaScript is garbage collected, so the kinds of memory leaks that Valgrind detects in C don't even exist as a concept in JavaScript.
Sure, I understand that; in JS the GC manages the memory for you, but still, there are memory leaks and there are no tools to deal with these. And that really surprises me. Is it because of some technical limitations? Or maybe browsers just haven't evolved yet up to that point? Or maybe there is just not enough demand for such tools?
Consider this C code:
#include <stdio.h>
#include <stdlib.h>
int main(void) {
size_t sz = 0;
void *unused = NULL;
for(;;) {
int n = 0;
void *tmp = realloc(unused, ++sz);
if(!tmp) break;
unused = tmp;
puts("Enter a number and I'll double it, or enter 0 to end:");
scanf("%d", &n);
if(!n) break;
printf("%d\n", 2*n);
}
free(unused);
}
I might have such a thing, though it has been over a decade since I did any webdev; not sure I still have the code. I was doing the backend for a project while the frontend work was being done by a guy in SF (I was in London). So remote working, all those issues, etc.
He kept delaying on giving me code until the client (and I) got upset enough. The code he gave me was garbage despite his claims of really knowing Javascript (very good interviewer...). It was horribly slow, unfinished and I spent two weeks trying to comprehend it so I could make a decision as to throw it all out or patch it.
One of the biggest problems turned out to be a function or something (details are fuzzy) that was generating a object that corresponded to the data/information the user would see in the UI. His code was not tracking whether a specific object had already been generated (i.e. no need to generate a new copy if the data was already been shown) so in the end, far too many copies of these little objects were being created - and kept around.
So it was a memory leak, but the memory wasn't getting lost, just forgotten about (if that makes sense). Enough time and the browser would get really slow, etc. Thank god for infinite RAM! (not)
Fortunately I learned my trade fixing problems with Borland's heap management (don't ask me for any details, that was 30 years ago) so I had the leet skills and patience to track down every last byte of RAM... This was before any fancy tools from Chrome were available, AFAI remember.
Never used Valgrind or know what the current state of the art is in regard to web dev / Javascript, but keeping track of RAM usage in Javascript (or Python or ...) is always a necessary task to pay attention to.
He kept delaying on giving me code until the client (and I) got upset enough. The code he gave me was garbage despite his claims of really knowing Javascript (very good interviewer...). It was horribly slow, unfinished and I spent two weeks trying to comprehend it so I could make a decision as to throw it all out or patch it.
One of the biggest problems turned out to be a function or something (details are fuzzy) that was generating a object that corresponded to the data/information the user would see in the UI. His code was not tracking whether a specific object had already been generated (i.e. no need to generate a new copy if the data was already been shown) so in the end, far too many copies of these little objects were being created - and kept around.
So it was a memory leak, but the memory wasn't getting lost, just forgotten about (if that makes sense). Enough time and the browser would get really slow, etc. Thank god for infinite RAM! (not)
Fortunately I learned my trade fixing problems with Borland's heap management (don't ask me for any details, that was 30 years ago) so I had the leet skills and patience to track down every last byte of RAM... This was before any fancy tools from Chrome were available, AFAI remember.
Never used Valgrind or know what the current state of the art is in regard to web dev / Javascript, but keeping track of RAM usage in Javascript (or Python or ...) is always a necessary task to pay attention to.