AFAIK, JQuery HTML constructors use document fragments behind the scenes. See http://www.bennadel.com/blog/2281-jQuery-Appends-Multiple-El... . No need for explicit document.createDocumentFragment
Writing Fast, Memory-Efficient JavaScript
11–20 of 32 posts
Re: Writing Fast, Memory-Efficient JavaScript
#12> Never use delete. Ever.
To "delete" is appropriate for hash-like structures, i.e., key-value maps. The runtime can't optimize these anyway; they will always be "generic slow objects". Plus, delete is the only way to remove the key, otherwise your hash will only grow in size, and you'd store a lot of "null" values for no reason that you'd have to explicitly filter.
Re: Writing Fast, Memory-Efficient JavaScript
#13This is good stuff. As I'm working on my game for github's game off, I was thinking about writing something similar. It doesn't bother me that's it's V8-centric, because devs are going to write about what they know the best. My article probably would have been SpiderMonkey focused.
Not sure I'll write it anymore though, this seems to have most of what I was going to say!
EDIT: After reading the article in more details, there are a few things I think it misses. My focus is more on games though. I still might write another article.
Re: Writing Fast, Memory-Efficient JavaScript
#14The 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…
Although it is possible that virtual machines change more rapidly than physical machines, isn't this also true for languages more directly targeting a physical machine, e.g. C?
I suppose what you're really getting at is that in JS we are subject to the whims of BOTH the compiler and the VM on the target browser?
Re: Writing Fast, Memory-Efficient JavaScript
#15Avoiding nested anonymous functions is good for more reasons than listed in the article. The article lists closures holding references to the closed-over variables as being a source of wasted memory. Another point is the fact that anonymous variables require memory allocation each time they are created:
// Uses more memory:
Foo.prototype.someFunction = function () {
;[2, 5, 9].forEach(function (element, index, array) {
console.log("a[" + index + "] = " + element)
})
}
// Uses less memory:
Foo.prototype.logArrayElements = function (element, index, array) {
console.log("a[" + index + "] = " + element)
}
Foo.prototype.someFunction = function () {
;[2, 5, 9].forEach(this.logArrayElements)
}
Re: Writing Fast, Memory-Efficient JavaScript
#16> 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 t…
Agreed. But I'd worry about something like this once I notice I want to improve performance. In the book Beautiful Code one of the authors urged programmers to write beautiful code first then optimize when needed later. It's easier to optimize beautiful code than it is to beautify optimized code. Using delete is a very readable statement of intent.
Re: Writing Fast, Memory-Efficient JavaScript
#17Avoiding nested anonymous functions is good for more reasons than listed in the article. The article lists closures holding references to the closed-over variables as being a source of wasted memory. Another point is the fact that anonymous variables require memory allocation each time they are created: // Uses more memory: Foo.prototype.someFunction = function () { ;[2, 5, 9].forEach(function (element, index, array)…
Why an expression and not simply `function logArrayElements`? If you do the latter you'll see more information if you wanted to introspect (toString on the function, or in an error traceback).
Re: Writing Fast, Memory-Efficient JavaScript
#18Avoiding nested anonymous functions is good for more reasons than listed in the article. The article lists closures holding references to the closed-over variables as being a source of wasted memory. Another point is the fact that anonymous variables require memory allocation each time they are created: // Uses more memory: Foo.prototype.someFunction = function () { ;[2, 5, 9].forEach(function (element, index, array)…
In both examples, the function is only allocated once, no matter how it's instantiated.
Where you have to be careful is if you have a function that's being called repeatedly and it contains a function instantiation -- that function will be reallocated each time.
[1,2,3].forEach(function(x) {
return (function(a, b) { return a * b })(x, 2)
})
mul = function(a, b) { return a * b }
;[1,2,3].forEach(function(x) {
return mul(x, 2)
})
Re: Writing Fast, Memory-Efficient JavaScript
#19V8 is not the only javascript engine.
No, but modern javascript engines share many traits that make these tips generally relevant across engines (although they may be more or less true for specific engines and there may be exceptions) The author is clear that the article is focused on V8. Here's a similar link from microsoft describing optimization suggestions for its Chakra engine that makes very similar recommendations: http://msdn.microsoft.com/en-us/library/windows/apps/hh78121...
Re: Writing Fast, Memory-Efficient JavaScript
#20AFAIK, JQuery HTML constructors use document fragments behind the scenes. See http://www.bennadel.com/blog/2281-jQuery-Appends-Multiple-El... . No need for explicit document.createDocumentFragment
That's internally in jQuery though, which does you no good at all if you're invoking DOM manipulation methods yourself -- such as the example in the article, the code is calling append() inside of a loop. Each one of those calls has no knowledge of the other though, and so it cannot possible do this for you.