This is the biggest thing that jumped out at me:
OTP-14894 Application(s): compiler
Related Id(s): ERL-714
The compiler has been rewritten to internally use an
intermediate representation based on Static Single
Assignment (SSA). The new intermediate representation
makes more optimizations possible.
Most noticeable is that the binary matching
optimizations are now applicable in many more
circumstances than before.
Another noticeable change is that type optimizations
are now applied across local function calls, and will
remove a lot more redundant type tests than before.I wrote a blog post describing some of the highlights in greater detail
Much appreciated, thank you!
I just watched https://www.youtube.com/watch?v=N_qaz5Dny9k and on the topic of âFragmented distribution messagesâ I noticed it sound just like the erlang schedulers for network messaging 
Itâs interesting that youâre now omitting type checks through âwhole moduleâ analysis. Are there any performance improvements to be had from distinguishing from floats and integers?
I am also interested in more information about the in-module type check analysis:
Does this mean that when repeatedly pattern-matching on the type of a variable whose type is already known (like an Erlang record or an Elixir struct (AKA a map with a certain __struct__ key?)), that these will be completely elided?
This would be amazing, since it is very common to use e.g. public functions of a library (that pattern match on the data structure passed in to prevent incorrect usage by library users) inside the implementation of other functions in the library as well.
As an example, in the vectors/matrices/tensors library âtensorâ, the function Tensor.Matrix.symmetric?/1 function internally calls the function Tensor.Matrix.transpose/1 on its parameter. Since both of these functions are public, both of these check if the data structure passed in is a matrix (i.e. a %Tensor{} struct where the âdimensionsâ field is a list of length 2).
If these kinds of duplicate checks are optimized away, that would be really cool! 
Amazing work, Erlang Core team! 
Since Erlang allows integers of arbitrary size, it is difficult to optimize integer arithmetic. Even if we would introduce special operations for integer arithmetic, we would not gain much because those operations would have to check that the result of the operation would still fit in a smallnum.
It is easier to optimize floating point instructions, since the size of the result is fixed (a 64-bit floating point number). In fact, BEAM has special instructions for floating point arithmetic and has had them for a long time (since OTP R7 or R8, I think). The new whole module type analysis helps those floating point optimizations by finding more places where general arithmetic operations can be replaced with floating point instructions.
The type analysis currently keeps track of the types of all elements in tuples and will omit unnecessary type tests for known elements. (That also cover Erlang records, since they are tuples.)
Currently, the type analysis pass does not keep track of the keys or values for maps. It only keeps tracks of variables that are maps, so that the is_map test can be omitted, but there will be repeated tests for __struct__.
We plan to improve the type analysis pass in OTP 23 and it is very likely that it will be extended to keep track of keys and values in maps.
I was mainly thinking of the fact that a hypothetical strongly typed language on the BEAM could compile to âtype-erasedâ code directly.
Shouldnât OTP 22 have embedded documentation that I can read from iex using h/1?
I still got the message that this were not supported on my machine earlier today. (Arch Linux, installed from packages)
EEP-48 is one of the Erlang Ecosystem Foundationâs objectives for OTP-23.
