Add passes compress option. Fix duplicate compress warnings.

[kzc]

Added new method Compressor.prototype.compress(node) to facilitate the passes=n optimization to further compress code in some cases.

Also added basic sanity test for minify().

[rvanvelzen]

I'm not sure whether introducing iterations is a good solution. It works, obviously, but it'd be much nicer to fix the core issue.

[kzc]

There is no single core issue. It's not specific to this particular issue or any individual optimization. Finding a perfectly optimal compress algorithm in all situations is intractable because of the order in which individual AST node optimizations are applied - particularly when compress options are enabled or disabled in different combinations. What optimization order works best for one JS program will not necessarily be optimal for another. Presently uglify marks an AST node as being optimized to prevent an infinite compress cycle as transformed code can flip/flop between states. The default would remain at a single pass and run at the same speed. Giving the user the option to run the compress pass more than once to squeeze extra bytes from their JS at the expense of uglify running for a little more time is a good compromise, and it is not uncommon in compilers.

[kzc]

$ bin/uglifyjs --self -m -c warnings=false,collapse_vars=1,passes=1 | wc -c
  127631

$ bin/uglifyjs --self -m -c warnings=false,collapse_vars=1,passes=2 | wc -c
  127607

[kzc]

@mishoo Any objection to merging this PR?

[rvanvelzen]

I stand by my previous words, but I don't see a reason not to include this option anyway. Merged as c55dd5e, thanks!

[kzc]

passes is optional. The default is still the same - 1 pass.

I've observed passes=2 drop unnecessary parentheses around expressions, and braces from loops with single statement bodies, further optimize ternary and boolean expressions, drop unused variables to create longer sequences. Probably a few other optimizations as well. Very little code for this option. I don't see any downside.

[olsonpm]

@kzc Mind explaining the implicit maximum of 3 passes? My assumption is that it's an arbitrary "good enough" amount that prevents the user from shooting their foot. However I still feel it should be mentioned in the readme.

[kzc]

It is arbitrary. I haven't seen any JS input that produces smaller output with more than 3 passes, and each additional pass makes minification slower. If you can demonstrate code that appreciably benefits from a higher number we will reconsider increasing the value.

If you wish to make a PR mentioning its max value of 3, that would be great.

[olsonpm]

Makes sense - thanks so much.

I'm putting together a PR tackling the side_effects option with passes - since pure annotations are removed on the first pass, thus removing the benefit of multiple passes. I'm having a hard time creating a small reproduction of code that doesn't get fully minified in one pass though - it's an interesting problem.

[kzc]

since pure annotations are removed on the first pass, thus removing the benefit of multiple passes

That hasn't been my experience with #__PURE__ annotations. Test different passes settings in the following examples:

#1261 (comment)
#1261 (comment)
#1261 (comment)

Also, you can set an option to keep the pure annotation comments if you want uglify to emit them after minification.

Clarification: the /*#__PURE__*/ annotation is not set on a function, but a function call. I had missed that in the recent README doc fix.

[olsonpm]

hmm - thanks for the test references. Seems I need to better understand my problem.

[olsonpm]

Sorry for the misunderstanding - you were right and my issue was not thoroughly marking the functions I needed to. I'll put together the PR for max passes now.