Deoptimization guard

[emilos]

I'm curious whether it would make sense to introduce some kind of deoptimization guard, which does not apply the optimization (or maybe throws an error to tell that something is wrong) if the result does actually make the code longer that it was before the changes. Here's a contrived edge case example/bug:

Input:

(function({x}){doSomething(x)})

Output:

(function({x:a}){doSomething(a)})

31 B → 33 B (saved -6.5%)

[Rich-Harris]

Yes, that makes sense. I think shorthand properties is (currently) the only place where this could happen, so it would probably be handled inside the mangling logic rather than being a more general purpose thing.

[loilo]

I'd like to add that this guard should not be active when using the check option or be disableable (is that a word?) in any way. Otherwise tests with already minified sources will mostly be pointless.

[thisconnect]

Does parsing/loading speed matter https://github.com/nolanlawson/optimize-js within the optimization category?