tc39 / proposal-binary-ast

Binary AST proposal for ECMAScript
965 stars 23 forks source link

Introduce LiteralI32Expression #32

Open Yoric opened 6 years ago

Yoric commented 6 years ago

In practice, pretty much all integer literal numbers we encounter are within [|-2^31, 2^31[| (I believe that I have never seen an integer literal outside of this range). Experience shows that introducing the following is a pretty good filesize win:

typedef (LiteralF64Expression or LiteralI32Expression)
  LiteralNumericExpression;

interface LiteralF64Expression {
  attribute double value;
}

interface LiteralI32Expression {
  attribute long value;
}

Any objection to this? The assumption being that the long will be a variable length encoded integer.

ljharb commented 6 years ago

Just to contrast with “never”: https://github.com/es-shims/es5-shim/blob/master/es5-shim.js#L1141, for example. Certainly it’s not common.

Yoric commented 6 years ago

Well, I can now replace the above never with once, but that doesn't change the trend :)

ljharb commented 6 years ago

I would suspect that the trend is actually much, much smaller numbers than 32 bit.

Yoric commented 6 years ago

Yes, the most common numbers I encounter are actually 0 and 1. So I believe that we should actually specialize even further for these numbers. But variable-length encoding gives us in a single byte (+generally 1 byte header) all numbers between -63 and +64, which should cover most cases, in two bytes (+ header) -8191 to +8192, which should cover most of the rest.

Yoric commented 6 years ago

For context, I have modified the binary format to transparently bias towards i8, then i16, then i32. Numbers whose value doesn't fit in a i32 will take two more bytes, but experience shows that occurrences of this are nearly non-existent.

Another optimization being examined will automatically create a new pseudo-interface for common occurrences, including 0 and 1. So, this issue is not necessary anymore for compression reasons.