The answer is maybe.

Lets look at what the closure team says about it.

From the FAQ:

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.

我完全质疑他们在这里提出的第一个假设。 所用名称的大小并不直接影响到 Java的各种发动机如何对待代码-事实上,如果你称之为<条码>、代相传的密码>、<条码>或<条码>x(但我作为方案管理员确信这样做)。 下载时间是最重要的部分,如果你重新担心交付——如果操作缓慢的文字可能是由我怀疑工具根本无法说明的数百万件事情造成的。

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

我们:

• Carakan (Opera)
• Chakra (IE9+)
• SpiderMonkey (Mozilla/FireFox)
• SquirrelFish (Apple s webkit)
• V8 (Chrome)
• Futhark (Opera)
• JScript (All versions of IE before 9)
• JavaScriptCore (Konqueror, Safari)
• I ve skipped out on a few.

是否有任何人真的认为他们都这样做? 特别是J.S.和V8? Heck no!

So again, when google closure compiles code, which engine is it building stuff for? Are you feeling lucky?

奥凯,由于我们永远无法涵盖所有这些基地,我们就试图在这里更全面地看一看“旧”和“新”法典。

Here s a quick summary for this specific part from one of the best presentations on JS Engines I ve ever seen.

Older JS engines

• Code is interpreted and compiled directly to byte code
• No optimization: you get what you get
• Code is hard to run fast because of the loosely typed language

New JS Engines

• Introduce Just-In-Time(JIT) compilers for fast execution
• Introduce type-optimizing JIT compilers for really fast code (think near C code speeds)

这里的主要区别是,新的发动机引进了联合技术汇编者。

从本质上讲,国际投资协议将优化执行,使其能够更快地运行,但如果它像以前那样做的事情,它就会转而走,并再次放慢。

You can do such things by having two functions like this:

var FunctionForIntegersOnly = function(int1, int2){
    return int1 + int2;
}

var FunctionForStringsOnly = function(str1, str2){
    return str1 + str2;
}

alert(FunctionForIntegersOnly(1, 2) + FunctionForStringsOnly("a", "b"));

坚持道道关闭实际上使整个法典简化为:

alert("3ab");

该书的每个衡量标准都比较快。 这里确实发生的情况是,它简化了我真正简单的榜样,因为它确实是部分执行。 然而,这就是你们需要小心的领域。

让我们说,我们的《法典》中有一个综合工具,汇编者把它变成了这样的内容:

(function(a) {
 return function(b) {
    return a(a)(b)
  }
})(function(a) {
  return function(b) {
    if(b > 0) {
      return console.log(b), a(a)(b - 1)
    }
  }
})(5);

守则没有真正更快,只是简单明了。

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
• Old browsers don t have JIT but still run your code
• Closure compiled JS invokes less function calls by doing partial-execution of your code for simple functions.

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.