Writing Fast, Memory-Efficient JavaScript • Hacker News Board

Re: Writing Fast, Memory-Efficient JavaScript

#21

Post by beatgammit » Mon, Nov 05, 2012, 8:16 PM UTC

btipling wrote: post #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/de…

I completely agree.

The author mentions that programmers use delete for dereferencing. What?? That is completely opposite from what 'delete' means and should never be done, ever. Use 'delete' to remove keys from a map, not as a stupid GC hack. Also, 'null != undefined'. They have different meanings. null will show up in a for .. in loop, whereas a 'deleted' member is actually gone.

99% of performance problems are due to wrong code, not inefficient VMs. Write better code and you'll get faster programs. For those problems in the 1%, profile and fix.

Re: Writing Fast, Memory-Efficient JavaScript

#22

Post by tolmasky » Mon, Nov 05, 2012, 8:25 PM UTC

mmagin wrote: post #14

gioele wrote: post #8

The 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?

I can personally attest from first hand experience that "code rot" due to not taking advantage of the peculiarities of the current JS VM (and yesterday's "techniques" no longer being suitable) are far more commonplace than in any other programming environment I've dealt with.

Also of note -- with C you make your product, compile it, ship it and largely forget about it. Its rare that PC games get slower, even if compilers change, because you don't keep recompiling it. However, if you make a JS game, that thing is interpreted from scratch every time its loaded. So if I make a JS game and ship it, the performance characteristics have a higher chance of changing in unexpected ways on me long after I've moved on.

(Note: This is simply a response to this particular aspect of performance tuning JS, I am obviously not getting into the benefits of interpretation which may very well outweigh these costs.)

Re: Writing Fast, Memory-Efficient JavaScript

#23

Post by [deleted] » Mon, Nov 05, 2012, 8:38 PM UTC

gioele wrote: post #8

The 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…

[deleted]

Re: Writing Fast, Memory-Efficient JavaScript

#24

Post by cmwelsh » Mon, Nov 05, 2012, 9:05 PM UTC

isntitvacant wrote: post #18

cmwelsh wrote: post #15

Avoiding 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) }) Will repeatedly allocate that inner multiplication function, vs: mul = functi…

I think we are in complete agreement. Your example is a little prettier however you still have this "unoptimized" line:

  ;[1,2,3].forEach(function(x) {

If this line is executed more than once, the nested function will be created again and again, wasting memory. However, some people may see my advice here as a micro-optimization. Thus, don't make your code ugly until you identify the real-world bottlenecks. I have updated my code in the grand-parent comment to explain myself a little more clearly (maybe)...

Re: Writing Fast, Memory-Efficient JavaScript

#25

Post by cmwelsh » Mon, Nov 05, 2012, 9:10 PM UTC

btipling wrote: post #17

cmwelsh wrote: post #15

Avoiding 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).

I adapted this from some game engine code. I have updated my example to show why I wasn't using a `function` statement. Thanks.

Re: Writing Fast, Memory-Efficient JavaScript

#26

Post by saraid216 » Mon, Nov 05, 2012, 10:28 PM UTC

gioele wrote: post #8

The 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…

I would kind of like to read an article specifically about tuning performance in various IEs. (It would be, unfortunately, a very practical and useful article for me.)

Re: Writing Fast, Memory-Efficient JavaScript

#27

Post by 46Bit » Mon, Nov 05, 2012, 11:30 PM UTC

saraid216 wrote: post #26

gioele wrote: post #8

The 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…

I would kind of like to read an article specifically about tuning performance in various IEs. (It would be, unfortunately, a very practical and useful article for me.)

A while back I wanted to put a JSON information string and a fairly sizable 3D model in the same request response, and then pull the JSON off without nailing the browser if the model was big. I keep meaning to test how well it works in different browsers as well.

Re: Writing Fast, Memory-Efficient JavaScript

#28

Post by wizard_2 » Tue, Nov 06, 2012, 1:04 AM UTC

asolove wrote: post #2

For 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

One of my favorite talks about how an interpreter can work. It's worth watching even if you are not concerned with javascript.

Re: Writing Fast, Memory-Efficient JavaScript

#29

Post by strager » Tue, Nov 06, 2012, 2:35 AM UTC

jlongster wrote: post #13

This 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 detail…

I would love to read an article about optimizing for SpiderMonkey, or at least explaining what optimizations SpiderMonkey does differently than V8.

Re: Writing Fast, Memory-Efficient JavaScript

#30

Post by Groxx » Tue, Nov 06, 2012, 5:43 AM UTC

btipling wrote: post #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/de…

I don't know, those are awfully significant performance differences. On mine, the last is 357 times faster than the first - might be a test flaw, but yikes.

That said, this (and many others) is probably not a concern for most (even most JS heavy) sites, since most simply don't compute enough to impact the page as much as, say, reducing reflows.