A toddlers guide to memory leaks in JavaScript
1–10 of 12 posts
Re: A toddlers guide to memory leaks in JavaScript
#2All of these issues could’ve been avoided if we didn’t use functional programming. I think imperative languages are better because things like memory leaks and algorithmic errors are easy to conceptualize in the first place, hence less chance of typos.
Re: A toddlers guide to memory leaks in JavaScript
#3This is just “using lots of memory”, not a “leak”.
Re: A toddlers guide to memory leaks in JavaScript
#4All of these issues could’ve been avoided if we didn’t use functional programming. I think imperative languages are better because things like memory leaks and algorithmic errors are easy to conceptualize in the first place, hence less chance of typos.
All of these issues could’ve been avoided if we didn’t use imperative programming. I think functional languages are better because things like memory leaks and algorithmic errors are easy to conceptualize in the first place, hence less chance of typos.
Re: A toddlers guide to memory leaks in JavaScript
#5This is just “using lots of memory”, not a “leak”.
If you careful read the code
```
function sayHi() {
var allNames = [];
return name => {
allNames.push(name);
return ' ' + name;
}
}
```
It leaks memory on every invocation of the returned function
Re: A toddlers guide to memory leaks in JavaScript
#6This is just “using lots of memory”, not a “leak”.
In the context of a language with a working garbage collector, doesn't "memory leak" just mean "accidentally using lots of memory"?
Re: A toddlers guide to memory leaks in JavaScript
#7All of these issues could’ve been avoided if we didn’t use functional programming. I think imperative languages are better because things like memory leaks and algorithmic errors are easy to conceptualize in the first place, hence less chance of typos.
All of these issues could’ve been avoided if we didn’t use imperative programming. I think functional languages are better because things like memory leaks and algorithmic errors are easy to conceptualize in the first place, hence less chance of typos.
[deleted]
Re: A toddlers guide to memory leaks in JavaScript
#8Just monitor your production memory profile, and occasionally run load test on your app. It is fine.
Re: A toddlers guide to memory leaks in JavaScript
#9This is just “using lots of memory”, not a “leak”.
In the context of a language with a working garbage collector, doesn't "memory leak" just mean "accidentally using lots of memory"?
With cyclical references add "freed sometime between now and eternity".
If this is not a definition of a memory leak I don't know what is.
Re: A toddlers guide to memory leaks in JavaScript
#10Earlier quoted context omitted.
In the context of a language with a working garbage collector, doesn't "memory leak" just mean "accidentally using lots of memory"?
With cyclical references add "freed sometime between now and eternity". If this is not a definition of a memory leak I don't know what is.
Well no, cyclical references only stop the object from being deleted if it's still accessible. That's what the 'mark' part of 'mark and sweep' does - it marks all objects still accessible somehow from inside the program. Then the 'sweep' bit runs through all allocated blocks and frees the unmarked ones.
Now, if you're merely approximating garbage collection with reference counting then sure, you have a problem.