Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Introduce LiteralI32Expression #32

Open
Yoric opened this issue Apr 24, 2018 · 5 comments
Open

Introduce LiteralI32Expression #32

Yoric opened this issue Apr 24, 2018 · 5 comments
Assignees

Comments

@Yoric
Copy link
Collaborator

Yoric commented Apr 24, 2018

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.

@Yoric Yoric changed the title Introduce LiteralU32Expression Introduce LiteralI32Expression Apr 24, 2018
@ljharb
Copy link
Member

ljharb commented Apr 24, 2018

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
Copy link
Collaborator Author

Yoric commented Apr 24, 2018

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

@ljharb
Copy link
Member

ljharb commented Apr 24, 2018

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

@Yoric
Copy link
Collaborator Author

Yoric commented Apr 24, 2018

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
Copy link
Collaborator Author

Yoric commented May 26, 2018

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants