Open KimlikDAO-bot opened 6 months ago
Actually, in the advanced more, both number
s and bigint
s can be emitted in hexadecimal if it makes the output shorter (literals larger than a certain threshold which can be calculated)
If true
is transformed to !0, this optimization can also be considered, which may be equally effective.
This is a fair optimization request. We may not be able to prioritize this but we'd be happy to receive a PR of this change.
Could you point me to the file where literals are emitted?
I think you'd modify the code approximately here.
@brad4d Thank you. Where would the tests for this go?
(Responding since Bradford is out) tests should go in https://github.com/google/closure-compiler/blob/master/test/com/google/javascript/jscomp/parsing/ParserTest.java. (correction - https://github.com/google/closure-compiler/blob/master/test/com/google/javascript/jscomp/CodePrinterTest.java) Thanks for the PR!
(Correction to my previous comment - I should have said https://github.com/google/closure-compiler/blob/master/test/com/google/javascript/jscomp/CodePrinterTest.java, sorry)
Thank you. Added some tests. Let me know if there other testing surfaces
Long bigint literals written in hexadecimal format (such as
0x123456789ABDEFn
) should be kept as is. Currently GCC expands them to decimal bigint literals, which increases the compiled size significantly (up to ~20%).Example:
is transformed to
Many crypto libraries (hashing, verifiable computation, etc) include long list of large constants. Keeping such constants in hexadecimal form makes a big difference.
Writing the literals as
BigInt("0xabc")
is a workaround but is not ideal due to increased compiled size and runtime cost.This incurs up to 20% blow up in compiled code size.