> In OTP 22 we have completely re-implemented the lower levels of the Erlang compiler.

Meaning some performance improvements for bit syntax which in Erlang is used [EDIT: in some of the newer, external code; there are still many places where charlists are used] for strings. Some string BIFs got faster. This should translate directly to Elixir and its string handling functions performance.

> OTP 22 comes with a new experimental socket API. The idea behind this API is to have a stable intermediary API that users can use to create features that are not part of the higher-level gen APIs.

Other than the ease of extending the API there are some performance improvements, too.

> PR1952 contributed by Kjell Winblad from Uppsala University makes it possible to do updated in parallel on ets tables of the type ordered_set. This has greatly increased the scalability of such ets tables that are the base for many applications, for instance, pg2 and the default ssl session cache.

More concurrency, better performance.

> In OTP 21.3 the culmination of many optimizations in the ssl application was released. For certain use-cases, the overhead of a using TSL has been significantly reduced. [...] The bytes per second that the Erlang distribution over TSL is able to send has been increased from 17K to about 80K, so more than 4 times as much data as before.

Everything relying on ssl got faster.

> On OTP 22 the logging facility for ssl has been greatly improved and there is now basic server support for TLSv1.3.

Not sure about that, don't know the details of TLS. More/better logging is always welcome.

> In order to deal with the head of line blocking caused by sending very large messages over Erlang Distribution, we have added fragmentation of distribution messages in OTP 22. This means that large messages will now be split up into smaller fragments allowing smaller messages to be sent without being blocked for a long time.

You can send lots of data over to other Erlang nodes without chunking them yourself - other messages will still go through anyway. Great if you have such messages in your app.

> Three new modules, counters, atomics, and persistent_term, were added in OTP 21.2. These modules make it possible for the user to access low-level primitives of the runtime to make some spectacular performance improvements.

> For instance, the cover tool was recently re-written to use counters and persistent_term [...] now it uses counters and the overhead of running cover has decreased by up to 80%.

> A fun (and possibly useful) use case for atomics is to create a shared mutable bit-vector. So, now we can spawn 100 processes and play flip that bit with each other

More tools for performance optimization is always welcome. Shared bit vector is an impressive example, but I'm not sure what else could be done with the modules, I didn't read their docs yet.

> In OTP 21.3, the version when all functions and modules were introduced was added to the documentation.

Great. It's implemented for many other langs' docs and is useful. All the docs were regenerated and the info about the version which introduced them was added to all the functions all over the place.

> In OTP 22 a new documentation top section called Internal Documentation has been added to the erts and compiler applications. The sections contain the internal documentation that previously only has been available on github so that it easier to access.

Better docs on internals is always a good thing. Could potentially save some work for other OTP langs implementers, including Elixir.

> Each major OTP release wouldn’t be complete without a set of memory allocator improvements and OTP 22 is no exception. The ones with the most potential to impact your applications are PR2046 and PR1854. Both of these optimizations should allow systems to better utilize memory carriers in high memory situations allowing your systems to handle more load.

Good. (not sure what else I could say here...)

Source: http://blog.erlang.org/OTP-22-Highlights/

In general, it looks like this release is focused on the optimization of many parts of the platform. Especially string handling improvements are welcome and will affect many Erlang-based (ie. including other OTP languages if I understand correctly) applications out there. That's good. Erlang being "slow" was always its weakest point which came up in nearly every discussion about Erlang. Great to see this is being actively addressed on many fronts. I'll definitely update my apps to use 22.

Congrats and thanks to all contributors!