Writing Fast, Memory-Efficient JavaScript
coding.smashingmagazine.com
Writing Fast, Memory-Efficient JavaScript
1–10 of 32 posts
Re: Writing Fast, Memory-Efficient JavaScript
#2For an in-depth look at what v8 does and doesn't do to optimize your code, see Vyacheslav Egorov's hilarious JSConf talk: http://blip.tv/file/6124796
Re: Writing Fast, Memory-Efficient JavaScript
#3> Never use delete. Ever.
...
This is horrible advice. There are plenty of things you want to delete, like references to elements when you don't need them anymore. A quick search of the Closure Library, jQuery, Backbone, Knockout, Angular.js, and ember.js found many uses of delete. Burn this article in a fire.
As for the supposed performance difference, let's see a jsperf on that.
Edit found one:
http://jsperf.com/delete-vs-undefined-vs-null/6
Delete is a little slower, certainly not enough to warrant the 'never' emphasis.
Re: Writing Fast, Memory-Efficient JavaScript
#4I'd love to see something like this for Apple's mobile Safari browser (on iOS).
Re: Writing Fast, Memory-Efficient JavaScript
#5> Never use delete. Ever. ... This is horrible advice. There are plenty of things you want to delete, like references to elements when you don't need them anymore. A quick search of the Closure Library, jQuery, Backbone, Knockout, Angular.js, and ember.js found many uses of delete. Burn this article in a fire. As for the supposed performance difference, let's see a jsperf on that. Edit found one: http://jsperf.com/de…
Certainly delete can be useful, but nulling a property has almost the same effect (apart from hasOwnProperty still returning true) - if you're looking at optimising at the level this article is talking about avoiding delete might well be sensible.
Re: Writing Fast, Memory-Efficient JavaScript
#6> Never use delete. Ever. ... This is horrible advice. There are plenty of things you want to delete, like references to elements when you don't need them anymore. A quick search of the Closure Library, jQuery, Backbone, Knockout, Angular.js, and ember.js found many uses of delete. Burn this article in a fire. As for the supposed performance difference, let's see a jsperf on that. Edit found one: http://jsperf.com/de…
Certainly delete can be useful, but nulling a property has almost the same effect (apart from hasOwnProperty still returning true) - if you're looking at optimising at the level this article is talking about avoiding delete might well be sensible.
This could also be horrible advice, because now you're mixing types which will make your code a little bit more complex, and you'll iterate over this null and have to deal with it. If you have an object property set to null you'll iterate over it, if you delete it you wont. As for the performance improvements, let's see the jsperf.
https://gist.github.com/4018282
Edit: I found a jsperf: http://jsperf.com/delete-vs-undefined-vs-null/6
Delete is a little slower, but setting null can be too, and setting undefined is the fastest for me in stable chrome.
Re: Writing Fast, Memory-Efficient JavaScript
#7> Never use delete. Ever. ... This is horrible advice. There are plenty of things you want to delete, like references to elements when you don't need them anymore. A quick search of the Closure Library, jQuery, Backbone, Knockout, Angular.js, and ember.js found many uses of delete. Burn this article in a fire. As for the supposed performance difference, let's see a jsperf on that. Edit found one: http://jsperf.com/de…
I think the better take away might be: avoid changing the structure of 'hot' objects at runtime.
JS engines will zero-in on these 'hot' objects and attempt to optimize access to it, a task which will be helped if object doesn't change in structure over its life-time. 'delete' will trigger such a structure change.
By structure in context of JS, one should think inferrable structure like always setting .a to a Number then .b to a String after instantiating an object.
Re: Writing Fast, Memory-Efficient JavaScript
#8The title should be "Writing JavaScript code that turns out to be fast and memory-efficient in the 2012 editions of JS engines".
When discussing the efficiency of a language, especially an interpreted language, one must always take into account the peculiarities of the used VM. And be sure that today's optimisations may be "pessimizations" in the future (see the many Linux optimisations that are being removed in the last years).
Re: Writing Fast, Memory-Efficient JavaScript
#9V8 is not the only javascript engine.
Re: Writing Fast, Memory-Efficient JavaScript
#10I think this guy makes an interesting point about performance, related issues stemming from using Delete. However, maybe the proper advice would be to Google and other folks who optimize javascripts execution to improve the handling of Delete, because is a necessary feature of frameworks.