Compile-time evaluate constant BitArray int segments on JavaScript #3798
+440
−132
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Implements #3724.
Details
Int
s in bit array expressions with a known value and size at compile time are now evaluated to bytes instead of usingsizedInt()
at runtime.Int
s in bit array patterns with a known value and size at compile time are now evaluated then matched byte-wise instead of usingintFromSlice()
at runtime.The above is currently limited to
Int
sizes <= 48 bits in order to be under the JS safe integer limit, because otherwise:<<0:8192>>
would evaluate to[0,0,0,0, ...]
to 1024 entries, which seems undesirable (though I'm not sure if such code is commonly encountered).let assert <<0xFFFFFFFFFFFFFFFF:64>> == <<255, 255, 255, 255, 255, 255, 255, 255>>
would change behaviour, albeit in a correct direction that would match Erlang. This may be desirable, but I've taken the conservative route initially.Performance
Evaluating
<<-1:32>>
: 10-11x faster.Evaluating a large lookup table of 16-bit integers: 26x faster.
Pattern matching a 32-bit signed integer: 2.7-7.1x faster, depending on how early a non-matching byte occurs.
Generated JavaScript code size is up to ~70% smaller. There are a few cases when using 40-bit and 48-bit wide integers that can see code size increases of ~20% with certain values, but the average case still sees a code size reduction on the wider integers.