3 Answers
3

The answer is maybe.

Does the compiler make any trade-off between my application's execution speed and download code size?

Yes. Any optimizing compiler makes trade-offs. Some size optimizations do introduce small speed overheads. However, the Closure Compiler's developers have been careful not to introduce significant additional runtime. Some of the compiler's optimizations even decrease runtime (see next question).

Does the compiler optimize for speed?

In most cases smaller code is faster code, since download time is usually the most important speed factor in web applications. Optimizations that reduce redundancies speed up the run time of code as well.

I flatly challenge the first assumption they've made here. The size of vars names used does not directly impact how the various JavaScript engines treat the code-- in fact, JS engines don't care if you call your variables supercalifragilisticexpialidocious or x (but I as a programmer sure do). Download time is the most important part if you're worried about delivery-- a slow running script can be caused by millions of things that I suspect the tool simply cannot account for.

To truthfully understand why your question is maybe, first thing you need to ask is "What makes JavaScript fast or slow?"

Then of course we run into the question, "What JavaScript engine are we talking about?"

Running that through google closure actually simplifies the whole code down to:

alert("3ab");

And by every metric in the book that's way faster. What really happened here is it simplified my really simple example, because it does a bit of partial-execution. This is where you need to be careful however.

JIT would normally see that in practice your code only ever takes two string inputs to that function, and returns a string (or integer for the first function), and this put it into the type-specific JIT, which makes it really quick. Now, if google closure does something strange like transform both those functions that have nearly identical signatures into one function (for code that is non-trivial) you may lose JIT speed if the compiler does something JIT doesn't like.

So, what did we learn?

You might have JIT-optimized code, but the compiler re-organizes your code into something else

So what do you do?

Write small and to-the-point functions, the compiler will be able to deal with them better

If you have a very deep understanding of JIT, hand optimizing code, and used that knowledge then closure compiler may not be worthwhile to use.

If you want the code to run a bit faster on older browsers, it's an excellent tool

Trade-offs are generally worth-while, but just be careful to check things over and not blindly trust it all the time.

In general, your code is faster. You may introduce things that various JIT compilers don't like but they're going to be rare if your code uses smaller functions and correct prototypical object-oriented-design. If you think about the full scope of what the compiler is doing (shorter download AND faster execution) then strange things like var i = true, m = null, r = false; may be a worth-while trade off that the compiler made even though they're running slower, the total lifespan was faster.

It's also worthwhile to note the most common bottle neck in web-app execution is the Document Object model, and I suggest you put more effort over there if your code is slow.

@John I fully understand the statement, but I'm not sure where I was unclear. I did state "Download time is the most important part if you're worried about delivery-- a slow running script can be caused by millions of things that I suspect the tool simply cannot account for." Can you point it out so I can fix it? I mention the DOM at the end of the post as well.
–
IncognitoNov 10 '11 at 2:24

2

Excellent answer, but I can't help worrying that the JIT compiler might have more trouble inlining and partially evaluating the "constant" value if it's in a variable, which could conceivably be re-assigned later.
–
andrewmuNov 10 '11 at 12:27

2

@incognito: to quote: "I flatly challenge the first assumption they've made here. The size of vars names ..." We didn't make that assumption. Where did you get the idea that the Closure Compiler equates variable name size with runtime performance? However, the startup time of an application is highly correlated to the time it takes to download the code and there (sadly) every byte counts. This fact has only gotten worse over the last decade as the mobile platforms have become significant with it high latency/low bandwidth/low reliability connects, subpar processors and tiny browser caches.
–
JohnNov 15 '11 at 16:11

2

I should clarify that barring the strange beginning the general assessment is sound, but I would add that it is difficult to "tune to the JIT" as there are no less than 4 major engines (one for each of the major browsers, with out considering upcoming engines) each of which have different characteristics
–
JohnNov 20 '11 at 2:00

It would appear that in modern browsers using the literal true or null vs a variable makes absolutely no difference in almost all cases (as in zero; they are exactly the same). In very few cases, the variable is actually faster.

I think there will be a very slight performance penalty, but unlikely to matter much in newer, modern browsers.

Notice that the Closure Compiler's standard alias variables are all global variables. Which means that, in an old browser where the JavaScript engine takes linear time to navigate functional scopes (e.g. IE < 9), the deeper you are within nested function calls, the longer it takes to find that variable which holds "true" or "false" etc. Almost all modern JavaScript engines optimize global variable access so this penalty should no longer hold in many cases.

In addition, there really shouldn't be many places where you'd be seeing "true" or "false" or "null" directly in compiled code, except for assignments or arguments. For example: if (someFlag == true) ... is mostly just written if (someFlag) ... which is compiled by the compiler into a && .... You mostly only see them in assignments (someFlag = true;) and arguments (someFunc(true);), which really do not happen very frequently.

Conclusion is: although many people doubt the usefulness of the Closure Compiler's standard aliases (me included), you shouldn't expect any material performance hit. You also shouldn't expect any material benefits in gzipped sizes, though.

FYI: "if (someFlag === true) ..." is not folded to "a && ...". Generally, the Closure Compiler does this kind of rewriting without knowledge of the values that can be held by the variables, and "a === true" could only become simply "a" if its only possible values were "true" and so-called falsy values (false, null, undefined, etc).
–
JohnNov 15 '11 at 16:21