Obfuscate boolean literals in output

[zbynek]

To reduce the output length in obfuscated mode, false should be encoded as !1 and true as !0.
This is a common practice for JS minifiers, such as terser.

[niloc132]

Closure-compiler does it too - I hesitate for a lot of these as I'm not sure where we would draw the line between "make it smaller" and "make the JS runtime work harder, run code slower". I assume that the proliferation of this approach means that it will not have a performance impact. Also, gzip/brotli/etc will do a great job with keywords like this, and the impact ought to be minimal after compression.

We could also just alias these as constants, e.g. y=true,z=false at the top of the program, it could turn out to be smaller overall - though we have another old bug report (can't find it right now) that suggested that some JS engines are slower with this bit of indirection.

[zbynek]

Actually with gzip this optimization is still measurable. I shared some stats in #10279 (comment) --
when followed by mass replace of true/false the gzipped size went to 2549310, so 0.17%.

Using brotli it goes from 1840221B to 1836496B, so 0.2%, the gain without compression is 0.7%.

[vjay82]

But the concern seems valid. Do current JS engines "understand" what is done there or are they evaluating the expression again and again? In 2. case, is it really worth it?

[zbynek]

I'm pretty sure V8 uses constant folding to avoid actually evaluating this multiple times. How much time it needs to do said constant folding vs how much time is saved on transmitting + decompressing the file, I don't know. But since minifiers like esbuild or terser do it, I assume the performance loss is negligible (couldn't find any benchmark though).

[niloc132]

Surprising about brotli - and about how many true/falses your project has in compiled source. Also how many true/false strings your app must have to gain nearly 1% just by cutting those roughly in half? If an app was 200,000 bytes, and contained
500 false strings (picking false as the "best case"), it would save 1500 bytes, down to about 39,700, about 0.75%, right?
I guess that tracks - showcase is around 240,000 bytes, with about 562 (some might be string literals, didnt look more closely) in one permutation's source.

If we don't pay a penalty to evaluate !1 for example as a parameter to a function inside a tight loop, that definitely seems worth it. Knowing that terser, esbuild, closure all do it, we'd be in good company at least.

Might want to leave it as true/false in PRETTY/DETAILED for easier reading.

[jnehlmeier]

If we don't pay a penalty to evaluate !1 for example as a parameter to a function inside a tight loop, that definitely seems worth it. Knowing that terser, esbuild, closure all do it, we'd be in good company at least.

Constant folding can only happen during a compilation step (and to a limited extend during parsing) and that compilation will only happen once the runtime decides that the code path is a hotspot and it is allowed to spend some time analyzing the code to produce optimized machine code.

I am pretty sure in the showcase example there are no hotspots because most of the time these true/false values are simply UI related and a replacement with !1 would cost a theoretical penalty as the interpreter does no optimizations.

Maybe terser, esbuild, closure all do it primarly for file size with the assumption that it doesnt make a performance difference in event based UI code and if the code really becomes a hotspot then it will be constant folded once compiled.

String based constant folding during parsing

V8 JIT compiler deep dive

[jnehlmeier]

In https://medium.com/@suleif/v8-exploitation-primer-5ee8ad23bfca it is also said that V8 has actually three JIT compilers with different objectives:

1. Sparkplug: A non-optimizing compiler that is designed to compile machine code very fast (Called when the function reaches ~10–100 calls)
2. Maglev: A mid-tier compiler that balances producing optimized machine code and fast compilation times (~100–1000 calls)
3. Turbofan: The flagship compiler that produces highly optimized machine code (~1000+ calls)

So the remaining question is if Maglev already does constant folding or if only Turbofan does it.

[vjay82]

If it is optimized in hot code, that should be probably ok enough...

(In our business application(s), however, many weeks have been invested to improve performance while on the other hand ... the JS file is downloaded once and cached like forever. I understand for others size might be the primary focus.)

If constant folding is a thing, would the output benefit from GWT supporting const instead of only/old var keyword? Might be a low hanging fruit. I once read somewhere that it makes no difference but that might be outdated.

[niloc132]

@jnehlmeier I think it is likely that this is handled somewhat earlier than JIT, though I could be mistaken - this is the kind of thing I would expect the parser itself could handle as a common enough construct? I believe even asm.js uses it? ! is explicitly an int operator in asm.js, which lends itself to this sort of thing.

Probably we should get confirmation (either our own testing or lean on testing that some other minifier has done) for this kind of change though.

[zbynek]

I think this case is covered by V8 parser:
https://github.com/v8/v8/blob/9bb6c30cfb8ea794dc29c8caca06a38d4ad145cd/src/parsing/parser.cc#L434
so long before maglev/turbofan.

Also how many true/false strings your app must have

11447 false and 10990 true, so roughly 100KiB out of 7.4MiB

[niloc132]

@vjay82 Last I checked (admittedly, more than a year ago), const and let cost more than they gain in performance - in theory a runtime could validate them and then trust them better, but in practice it apparently doesn't work that way (or didn't). Plus, const would add a lot - whereas showcase has 500ish bool literals, it has more than 1000 vars, and the use of const would require some of those to be split.

[jnehlmeier]

I think this case is covered by V8 parser: https://github.com/v8/v8/blob/9bb6c30cfb8ea794dc29c8caca06a38d4ad145cd/src/parsing/parser.cc#L434 so long before maglev/turbofan.

Nice! In SpiderMonkey/Firefox there is an AST visitor which does the folding during during/after parsing: https://searchfox.org/firefox-main/source/js/src/frontend/FoldConstants.cpp#673

So it shouldn't be any problem to rewrite the booleans.