search

Rich-Harris / butternut

The fast, future-friendly minifier
https://butternut.now.sh
MIT License
1.17k stars 17 forks source link

Deoptimization guard #72

Open emilos opened 7 years ago

emilos commented 7 years ago

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 commented 7 years ago

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 commented 7 years ago

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 commented 7 years ago

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