proposal-binary-ast icon indicating copy to clipboard operation
proposal-binary-ast copied to clipboard

Details on size overhead comparisons

Open ojhunt opened this issue 7 years ago • 1 comments

It is unclear to me from the documentation provided whether the size savings specified are the result of the format essentially requiring compression as part of its specification, vs actually being meaningfully smaller; esp. compared to minified code+gzipped code that is currently the de jure deployment.

I ask because this is a significant body of new codegen, and new parsers with new attack surface -- I think it is reasonable to know how the size of the binary AST compares to the size of a standard conforming JS in a normal tool assisted environment (which to be clear, the binary AST would require).

ojhunt avatar Aug 02 '17 05:08 ojhunt

Based on an early experiment, we got the following size changes:

  • starting from code that is minimized + gzipped => -5%
  • starting from code that is non-minimized + gzipped => -70%

By opposition to minimization, compression to a binary AST does not lose variable names, etc. There is even a proposal (issue #11) to keep meaningful comments.

The format has been significantly changed since then, so we do not have up-to-date numbers for the latest format, but I expect that this will be the same ballpark.

Yoric avatar Aug 02 '17 06:08 Yoric