Note, this was written over a year ago, so stuff may have changed since then. It would probably be worth taking a look to see how things have improved.
Google Closure: How not to write JavaScript
11–20 of 51 posts
Re: Google Closure: How not to write JavaScript
#12My feeling is that even the compilers written in CS101 will optimize this. I'm guessing that Google tested their code with V8, performance was fine, and they thought nothing of it. I just did a benchmark with node.js. I made a 50000000 element array, and timed how long each way took. Trial one: for( var i = 0; i That took, on average, 0.93001866 seconds. Trial two: for( var i = 0; i That took, on average, 0.809920 se…
A rounding error that causes a fast-paced Javascript game to crawl to a laggy stutter when repeated all over the place.
Regardless, the Closure Compiler (that the Closure Library is made to be used for) fixes this common case.
Another example where it's more than a rounding error: http://stackoverflow.com/questions/2573212/why-is-setting-ht...
Re: Google Closure: How not to write JavaScript
#13"I’m not sure what this pattern is called in Java, but in JavaScript it’s called a ‘memory leak’."
The comment is in regards to goog.memoize but is terribly backwards. The complaint about goog.memoize is that it will grow uncontrollably because it does not cap the size of the caching object. A memory leak is the inability of a program to free memory it has allocated.
Since js is garbage collected causing a memory leak involves creating a circular reference fooling the garbage collector into thinking that an object is still in use.
Re: Google Closure: How not to write JavaScript
#14Time in web applications is not used looking up array lengths - it's used in IO, layout, and DOM manipulation. If iterating through arrays was found to ever be a noticeable issue in practice, the Closure compiler could just be modified to emit more efficient code. That's one of the advantages of having the compiler - you don't have to make a convenience/readability trade. Closure was not thrown together by novices ne…
Here is an example of a real-world performance bottleneck that was discovered by the closure team:
Re: Google Closure: How not to write JavaScript
#15My feeling is that even the compilers written in CS101 will optimize this. I'm guessing that Google tested their code with V8, performance was fine, and they thought nothing of it. I just did a benchmark with node.js. I made a 50000000 element array, and timed how long each way took. Trial one: for( var i = 0; i That took, on average, 0.93001866 seconds. Trial two: for( var i = 0; i That took, on average, 0.809920 se…
For js running in a browser this does not matter but on a server this will make a huge difference.
Re: Google Closure: How not to write JavaScript
#16My feeling is that even the compilers written in CS101 will optimize this. I'm guessing that Google tested their code with V8, performance was fine, and they thought nothing of it. I just did a benchmark with node.js. I made a 50000000 element array, and timed how long each way took. Trial one: for( var i = 0; i That took, on average, 0.93001866 seconds. Trial two: for( var i = 0; i That took, on average, 0.809920 se…
Or a 13/80 difference, which is in the 15%+ range. It's a rounding error on a total time of many seconds, but not in the realm of the very fast.
Re: Google Closure: How not to write JavaScript
#17This article is over a year old.
True, but as someone who has a java background and is working on js, it's nice to know that switches suck in js :)
Re: Google Closure: How not to write JavaScript
#18"I’m not sure what this pattern is called in Java, but in JavaScript it’s called a ‘memory leak’." The comment is in regards to goog.memoize but is terribly backwards. The complaint about goog.memoize is that it will grow uncontrollably because it does not cap the size of the caching object. A memory leak is the inability of a program to free memory it has allocated. Since js is garbage collected causing a memory lea…
> A memory leak is the inability of a program to free memory it has allocated.
Unexpected memoization/caching also counts as a memory leak. There are (unfortunately) a few places in Closure Library where unexpected memoization might cause a memory leak.
> Since js is garbage collected causing a memory leak involves creating a circular reference fooling the garbage collector into thinking that an object is still in use.
Browser environments are expected to handle circular references. They don't fool garbage collectors, except in old versions of IE when a circular reference crosses the JScript/DOM boundary.
Re: Google Closure: How not to write JavaScript
#19My feeling is that even the compilers written in CS101 will optimize this. I'm guessing that Google tested their code with V8, performance was fine, and they thought nothing of it. I just did a benchmark with node.js. I made a 50000000 element array, and timed how long each way took. Trial one: for( var i = 0; i That took, on average, 0.93001866 seconds. Trial two: for( var i = 0; i That took, on average, 0.809920 se…
For js running in a browser this does not matter but on a server this will make a huge difference.
How many 50 million element arrays do you have?
My guess is that this makes no difference in real life. Should you write clean code that performs well? Yes. But should you be fixated on a tiny bug in Google's library? Nope. Send patch, get .0000000001 seconds per element back, and move on.