41–50 of 57 posts
Who is this article written for? There's a whole section on "What is memory?". If you are optimizing to remove memory leaks I really hope you already know what memory is.
Wait, is #3 for real? If that's the case it seems like a huge oversight.
Yeah. I thought so too (and still think so). SO post: https://stackoverflow.com/questions/19798803/how-javascript-... Chrome bug report: http://crbug.com/315190 Meteor blog (linked in article): https://blog.meteor.com/an-interesting-kind-of-javascript-me... Live example (will crash due to memory leak): https://s3.amazonaws.com/chromebugs/memory.html --- The reason this exists in all JS engines is for performance; it'…
Earlier quoted context omitted.
Would it be better to have to explicitly declare what variables you want to import into the closure like PHP or C++ do? C# also captures everything by default and reference which has tripped me up quite a few times.
That might help but it seems like either an implementation or language spec fix is in order. There doesn't seem to be a reason for a function without free variables to turn into a closure at all, thus preventing the issue.
Currently, the ECMAScript specification says nothing about GC.
And it seems every major JS engine has decided that this type of memory leak is okay.
So it's rather unlikely something will change.
Who is this article written for? There's a whole section on "What is memory?". If you are optimizing to remove memory leaks I really hope you already know what memory is.
In my experience there are (I don't know how many) some programmers who, given how they were taught/learnt, can do productive work but generally don't know computing/programming in the abstract e.g. Memory at the machine level, or type systems.
e.g. Memory at the machine level,
I think it's the other way around --- their usual level of abstraction is too high to understand such things...
or type systems
...and slightly too low to understand others.
Wait, is #3 for real? If that's the case it seems like a huge oversight.
having stuff do stuff for you is useful until it doesnt
WebKit uses a constraint-based garbage collector that does not rely on reachability alone. This is an improvement over the classical garbage collection algorithm.
> As of 2012, all modern browsers ship a mark-and-sweep garbage-collector. All improvements made in the field of JavaScript garbage collection (generational/incremental/concurrent/parallel garbage collection) over the last years are implementation improvements of this algorithm (mark-and-sweep), but not improvements over the garbage collection algorithm itself, nor its goal of deciding whether an object is reachable…
I can optimize CPU usage all I want, but only after I optimized for minimum allocations, the tiny, but noticeable lags now and then would disappear.
The average javascript-GC must be really simple/naive compared to seasoned workhorses like the JVM's various GCs.
There I can happily create millions of short-lived objects before getting problems in a single-user application.
I don't think using strict will prevent accidental global variables, such as this.var in global scoped function calls. Strictness main goal is to prevent inadvertently misspelled variables from going unnoticed.