Writing Fast, Memory-Efficient JavaScript

coding.smashingmagazine.com

31–32 of 32 posts

Re: Writing Fast, Memory-Efficient JavaScript

#31

Post by masklinn » Tue, Nov 06, 2012, 9:37 AM 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?

> isn't this also true for languages more directly targeting a physical machine, e.g. C?

No, because the core architecture is very stable and optimizes for existing programs, which uses the existing quirks of the previous architecture.

Not so for JS VMs.

Re: Writing Fast, Memory-Efficient JavaScript

#32

Post by legacye » Tue, Nov 06, 2012, 11:08 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…

@btipling

"Burn this article in a fire" :)

Looking back through my article I agree that stating delete should outright never be used didn't make sense. It's of course used in numerous JavaScript libraries and has a purpose in the language. I've updated the text to reflect my suggestion that it should be instead, avoided where possible. This advice stands as it's more difficult for V8 to optimize objects you're changing the structure of.

For others commenting on this thread, I've also taken account of some of your suggestions and tried to update the article to be as accurate as possible. Thanks for the input!

Post reply on HN