I came across this performance report of JavaScript code compressed using various minifiers and obfuscators. What is surprising is that apart from Closure advanced mode, in most cases all other minifiers output code that performs worse than uncompressed code. How do we explain that?

Scroll down to the end of the page to see the report. Here are screenshots:

Legend:

• Blue - YUI Compressor
• Red - Closure (advanced mode)
• Orange - Closure (basic mode)
• Green - JS Min
• Purple - JS Packer
• Light Blue - UglifyJS
• Pink - Uncompressed code

I came across this performance report of JavaScript code compressed using various minifiers and obfuscators. What is surprising is that apart from Closure advanced mode, in most cases all other minifiers output code that performs worse than uncompressed code. How do we explain that?

Scroll down to the end of the page to see the report. Here are screenshots:

Legend:

• Blue - YUI Compressor
• Red - Closure (advanced mode)
• Orange - Closure (basic mode)
• Green - JS Min
• Purple - JS Packer
• Light Blue - UglifyJS
• Pink - Uncompressed code

• javascript
• performance
• obfuscation
• minify

• 8 That's not really a duplicate @Barmar - yes, it's about obfuscation, but it talks about Java and C#, not JavaScript. – nnnnnn Commented Mar 17, 2013 at 8:25
• 1 I'm not sure operations peer second is really a great metric... Surely this just shows which obfuscator favours the simplest operations, and says nothing about the speed of the code as a whole... – Frances McMullin Commented Mar 17, 2013 at 8:30
• 3 @Ozzy, obfuscation/compression in JS is more about reducing the amount of data that needs to be sent to the browser. This makes the page load faster, of course you would be concerned with having it run faster as well. – Frances McMullin Commented Mar 17, 2013 at 8:36
• 1 @DavidMcMullin and this is done more efficiently by zipping the file rather than obfuscation, which could introduce bugs. yuiblog.com/blog/2006/03/06/minification-v-obfuscation – Ozzy Commented Mar 17, 2013 at 8:38
• 2 @Ozzy It's not a one or the other question, doing both will yield the smallest file size and the fastest load time. – Frances McMullin Commented Mar 17, 2013 at 8:39

3 Answers 3

First let me play devil's advocate: The code does not actually "perform" anything (nothing serious I mean, except for JS Packer). It's essentially a definition of functions, objects and properties.

JS Packer does not produce JavaScript code but rather compressed text that has to be unpacked at runtime. That's why it's much slower. Google Closure using Advanced Optimization replaces identifiers whenever possible. So there already has to be a performance advantage when parsing the script.

That said it is possible to sacrifice performance for code size. One example is replacing true and false with !0 and !1. It depends on the JavaScript engine though. It could be optimized by the engine before the first call, after it, after some calls, never ... who knows ;)

New Findings

I did some profiling in the meantime and realized that I forgot one thing: garbage collection. The influence can be enough to explain some of the differences between the scripts and the browsers (different engines!).

Combine that with the fact that the code doesn't do much and you have something. In one test I had a CPU Time for garbage collection of about 3% for uncompressed and 9%(!) for JSMin. Which means completely different results for almost equal code.

Even newer findings

When you run JSMin first it's faster than uncompressed. I tried this several times and always got the same result. This confirms the previous findings. I am pretty confident now, that we found the solution.

It seems you may have inadvertently confused minification with obfuscation.

To understand the two technologies, I will explain them separately.

Minification is a process where the size of a source file is reduced, and made into a format intended for more efficient machine readability. This is done by (a) removing comments and unnecessary whitespace, and possibly (b) replacing variable names with simple, incremental variable names often starting with one character. The resulting code still functions the same as the original code, but is theoretically faster for the browser to parse and compile.

Obfuscation is a technique where code is modified so that it is no longer recognizable as the original source code, and is often used to discourage the reverse-engineering of proprietary code. Some of the changes may have an overhead to them, for example code might be encrypted then decrypted again at runtime. That said, it is typical for a code obfuscator to also finish off the job by minifying the output.

One could consider minification to be a crude form of obfuscation though, but usually such processes are carried out more for performance and/or bandwidth purposes.

Yes, obfuscation can cause some performance issues but it is not true that minified code perform worse than uncompressed one. In fact, minified code perform better than uncompressed one. This is because, minfied code have a much shorter variable/function name thus making the referencing call to the allocated memory space much easier!