20

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:

enter image description here enter image description here enter image description here enter image description here

Legend:

  • Blue - YUI Compressor
  • Red - Closure (advanced mode)
  • Orange - Closure (basic mode)
  • Green - JS Min
  • Purple - JS Packer
  • Light Blue - UglifyJS
  • Pink - Uncompressed code
Dheeraj Vepakomma
  • 26,870
  • 17
  • 81
  • 104
  • possible duplicate of [Is there a performance hit when running obfuscated code?](http://stackoverflow.com/questions/2646216/is-there-a-performance-hit-when-running-obfuscated-code) – Barmar Mar 17 '13 at 08:23
  • 8
    That's not really a duplicate @Barmar - yes, it's about obfuscation, but it talks about Java and C#, not JavaScript. – nnnnnn Mar 17 '13 at 08:25
  • Why is it necessary to compare obfuscation with performance? If someone feels the need to obfuscate their code, I don't think performance will be a question. – Ozzy Mar 17 '13 at 08:29
  • 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 Mar 17 '13 at 08: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 Mar 17 '13 at 08:36
  • 1
    @DavidMcMullin and this is done more efficiently by zipping the file rather than obfuscation, which could introduce bugs. http://yuiblog.com/blog/2006/03/06/minification-v-obfuscation/ – Ozzy Mar 17 '13 at 08: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 Mar 17 '13 at 08:39
  • 1
    If the compressor packs the code in a way that it first has to unpack itself, then there's obviously the overhead of that. Further, for instance, compressors may substitute repetitive function names with strings (`a = 'getElementById'; document[a]();`), which likely has very different performance characteristics. – deceze Mar 17 '13 at 08:45

3 Answers3

8

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.

a better oliver
  • 26,330
  • 2
  • 58
  • 66
  • 2
    +1 for the code not doing anything. The only benchmarks that matter are your own. – Frances McMullin Mar 17 '13 at 10:37
  • Granted, the code really does not "perform" anything. So it's not representative of a good benchmark. Still, why does minified code perform worse *for this particular test*? JSMin, in particular, [simply omits some whitespace](http://www.crockford.com/javascript/jsmin.html). So why should it perform worse? – Dheeraj Vepakomma Mar 17 '13 at 11:50
  • There even are results where the performance of JSMin is equal to the uncompressed version. But the performance of JSMin seems strange to me too. Apart from that we have to consider 3 issues: 1. Parsing: Building the AST takes its share of the time, for this script in particular. 2. It all depends on the JavaScript Engine. The results vary heavily. 3. The framework itself, or the way it does the benchmarks, **could** have an influence in **this** case. I don't think so, but I can't say for sure. – a better oliver Mar 17 '13 at 12:26
  • To explain every difference would require the involvement of the browser vendors, I fear. Or inspecting the source code of the JS Engines ;) – a better oliver Mar 17 '13 at 12:26
0

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.

William
  • 309
  • 1
  • 9
-1

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!

spaceman12
  • 1,039
  • 11
  • 18