5 ms·

I use `delete object[key]` all the time to unset a property. I do think in the JS world the use of `new` is inconsistent, but avoiding the keyword does not rid

by Rygu 12y ago

I use `delete object[key]` all the time to unset a property. I do think in the JS world the use of `new` is inconsistent, but avoiding the keyword does not rid of that fact. Your new-less libraries may be consistent with each other, but not the rest of the JS world that do it their own way. (http://xkcd.com/927/ http://xkcd.com/927/) This seems like a problem the language should solve incrementally. Especially with ES6 classes and modules!

maga 12y ago
`delete` is harmful, consider setting property to `undefined` or `null` instead.
- kalms 12y ago
  Why is it harmful to delete a property that disappears forever?
  - drinchev 12y ago
    Because garbage collectors doesn't care if it is simply deleted. Setting it to undefined or null is better for speed http://bertanguven.com/preventing-memory-leaks-in-javascript-null-vs-delete/ http://bertanguven.com/preventing-memory-leaks-in-javascript...
    - zimbatm 12y ago
      This article is just badly written. It doesn't provide or make reference to a precise documentation of the issue. It's not clear whenever it applies to `delete x` or also `delete obj[x]`. It doesn't provide a reproductible use case or list of browsers that are affected. It mentions issues with scope but doesn't go in detail of which ones are triggering the issue. For what it's worth it might apply only to IE6. `delete obj[x]` removes not only the reference to the value but also the key which prevents other forms of memory leak.
      - drinchev 12y ago
        There is another one from "Smashing Magazine" [1], I think it's written better : > In quite a few discussions online about reclaiming memory in JavaScript, the delete keyword is brought up, as although it was supposed to be used for just removing keys from a map, some developers think you can force de-referencing using it. Avoid using delete if you can. In the below example, delete o.x does a lot more harm than good behind the scenes, as it changes o‘s hidden class and makes it a generic slow object. Although it's from 3 years ago it looks decent. The comments below are even more interesting than the article. [1] : http://www.smashingmagazine.com/2012/11/05/writing-fast-memory-efficient-javascript/ http://www.smashingmagazine.com/2012/11/05/writing-fast-memo...
  - aardvark179 12y ago
    It is going to depend partly on the internals of your JIT. Since JS objects are so mutable it's common to use their shape as the basic check for fast method dispatch. So if you take a Foo and add a property x then it will become a Foo(x). If you make lots of calls on objects of this shape then the method lookups will make it into inline caches and be very quick, calls against an object of shape Foo() or Foo(y) or Foo(x,y) will be treated separately. Inline caches for method dispatch are generally very small, so you'll omly get really fast dispatch for a few different shapes at any particular call site so the more consistent the shapes the more likely you are to keep the JIT happy.
    - kalms 12y ago
      Thanks. That explained it really well. Semantically it makes sense to me, but I didn't take the interpreter into account.
    - josteink 12y ago
      So your argument is that we should currently and in the future constraint our usage of language-features based on the current state of language-runtimes? How are we going to keep pushing the boundaries then? Had JS started with that sentiment, we would have a V8 JS runtime running about 100th the speed it does now for general purpose code, written with the aim of being as clear and reusable as possible. Personally I prefer good, clear and concise code, over code written trying to appease some secondary affects on the inside of a black box which is not guaranteed to stay the same. This is clearly an optimization, and I'm not saying all optimization is bad per se, but all optimization should be justified if it affects code-clarity. Are you sure these optimizations are warranted? Have you profiled your code and identified that this is a bottleneck for performance-critical sections of your code? A former Nvidia-engineer had a really good rant about what sort of things your thinking leads to: http://www.gamedev.net/topic/666419-what-are-your-opinions-on-dx12vulkanmantle/#entry5215019 http://www.gamedev.net/topic/666419-what-are-your-opinions-o... Key quote: "So the game is guessing what the driver is doing, the driver is guessing what the game is doing, and the whole mess could be avoided if the drivers just wouldn't work so hard trying to protect us." I agree it's not a direct analogue, but the same line of thinking still applies.
- Rygu 12y ago
  Thanks. Went for `undefined` because it's for query string building, where `null` still is a valid key-value combination.

by Rygu 12y ago

maga 12y ago

`delete` is harmful, consider setting property to `undefined` or `null` instead.

kalms 12y ago
Why is it harmful to delete a property that disappears forever?
- drinchev 12y ago
  Because garbage collectors doesn't care if it is simply deleted. Setting it to undefined or null is better for speed http://bertanguven.com/preventing-memory-leaks-in-javascript-null-vs-delete/ http://bertanguven.com/preventing-memory-leaks-in-javascript...
  - zimbatm 12y ago
    This article is just badly written. It doesn't provide or make reference to a precise documentation of the issue. It's not clear whenever it applies to `delete x` or also `delete obj[x]`. It doesn't provide a reproductible use case or list of browsers that are affected. It mentions issues with scope but doesn't go in detail of which ones are triggering the issue. For what it's worth it might apply only to IE6. `delete obj[x]` removes not only the reference to the value but also the key which prevents other forms of memory leak.
    - drinchev 12y ago
      There is another one from "Smashing Magazine" [1], I think it's written better : > In quite a few discussions online about reclaiming memory in JavaScript, the delete keyword is brought up, as although it was supposed to be used for just removing keys from a map, some developers think you can force de-referencing using it. Avoid using delete if you can. In the below example, delete o.x does a lot more harm than good behind the scenes, as it changes o‘s hidden class and makes it a generic slow object. Although it's from 3 years ago it looks decent. The comments below are even more interesting than the article. [1] : http://www.smashingmagazine.com/2012/11/05/writing-fast-memory-efficient-javascript/ http://www.smashingmagazine.com/2012/11/05/writing-fast-memo...
- aardvark179 12y ago
  It is going to depend partly on the internals of your JIT. Since JS objects are so mutable it's common to use their shape as the basic check for fast method dispatch. So if you take a Foo and add a property x then it will become a Foo(x). If you make lots of calls on objects of this shape then the method lookups will make it into inline caches and be very quick, calls against an object of shape Foo() or Foo(y) or Foo(x,y) will be treated separately. Inline caches for method dispatch are generally very small, so you'll omly get really fast dispatch for a few different shapes at any particular call site so the more consistent the shapes the more likely you are to keep the JIT happy.
  - kalms 12y ago
    Thanks. That explained it really well. Semantically it makes sense to me, but I didn't take the interpreter into account.
  - josteink 12y ago
    So your argument is that we should currently and in the future constraint our usage of language-features based on the current state of language-runtimes? How are we going to keep pushing the boundaries then? Had JS started with that sentiment, we would have a V8 JS runtime running about 100th the speed it does now for general purpose code, written with the aim of being as clear and reusable as possible. Personally I prefer good, clear and concise code, over code written trying to appease some secondary affects on the inside of a black box which is not guaranteed to stay the same. This is clearly an optimization, and I'm not saying all optimization is bad per se, but all optimization should be justified if it affects code-clarity. Are you sure these optimizations are warranted? Have you profiled your code and identified that this is a bottleneck for performance-critical sections of your code? A former Nvidia-engineer had a really good rant about what sort of things your thinking leads to: http://www.gamedev.net/topic/666419-what-are-your-opinions-on-dx12vulkanmantle/#entry5215019 http://www.gamedev.net/topic/666419-what-are-your-opinions-o... Key quote: "So the game is guessing what the driver is doing, the driver is guessing what the game is doing, and the whole mess could be avoided if the drivers just wouldn't work so hard trying to protect us." I agree it's not a direct analogue, but the same line of thinking still applies.
Rygu 12y ago
Thanks. Went for `undefined` because it's for query string building, where `null` still is a valid key-value combination.