Add option to aggressively inline all literals and consts #136
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This new inlining option does two things: - Inlines any variable which looks like a literal constant (`hasInitDeps` is false) and which does not appear in an lvalue position - Inlines any variable marked as `const` whatsoever. This can increase program size, if a large literal is inlined over and over. However, the idea is exactly why the Google Closure Compiler also always inlines constants: a (the?) major use-case of this minifier is for demoscene shaders, which are almost certainly going to be put through compression later anyway -- so what matters is the size after compression, not the actual output size. And reducing the redudancy that this inlining creates can be done by the compressor in way fewer bytes than declaring a new variable in the program text. https://github.com/google/closure-compiler/wiki/FAQ#closure-compiler-inlined-all-my-strings-which-made-my-code-size-bigger-why-did-it-do-that This option isn't the default; we likely want to do more testing to see if it actually works out that way in practise (and to make sure the output doesn't break things!) However, when I tested it on the two largest shaders in `tests/real` (`the_real_party...` and `lunaquatic`), it not only reduced gzip'd size but also raw output size too. So it may just be a win all-around anyway? - `the_real_party...`: 17708 -> 17699 (gzipped 5181 -> 5173) - `lunaquatic`: 7356 -> 7347 (gzipped 2745 -> 2739)
laurentlb
approved these changes
May 10, 2022
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This new inlining option does two things:
(
hasInitDepsis false) and which does not appear in an lvalueposition
constwhatsoever.This can increase program size, if a large literal is inlined over and
over. However, the idea is exactly why the Google Closure Compiler also
always inlines constants: a (the?) major use-case of this minifier is
for demoscene shaders, which are almost certainly going to be put
through compression later anyway -- so what matters is the size after
compression, not the actual output size. And reducing the redudancy that
this inlining creates can be done by the compressor in way fewer bytes
than declaring a new variable in the program text.
https://github.com/google/closure-compiler/wiki/FAQ#closure-compiler-inlined-all-my-strings-which-made-my-code-size-bigger-why-did-it-do-that
This option isn't the default; we likely want to do more testing to see
if it actually works out that way in practise (and to make sure the
output doesn't break things!) However, when I tested it on the two
largest shaders in
tests/real(the_real_party...andlunaquatic),it not only reduced gzip'd size but also raw output size too. So it may
just be a win all-around anyway?
the_real_party...: 17708 -> 17699 (gzipped 5181 -> 5173)lunaquatic: 7356 -> 7347 (gzipped 2745 -> 2739)