Exciting to see your ideas come to life!

How do you know which functions are pure? Especially when anonymous functions are involved?

Could you please expand on the tricks here (or share a link)? I assume some of those may be implementable in Elixir itself, since for is opaque (although it is unlikely we would do Enum fusion).

Curious: how would that be different from Erlang inlining via @compile :inlineand @compile {:inline, size}?

Any ideas here? We do compile map.field to a case statement but, last time I measured, the pattern matching was faster than invoking a BIF instruction (which is what Map.fetch! does). map.fieldshould be slower if the field does not exist though.

Other than that, nice work! I am sure the Erlang Compiler team would also be interested in further ideas to optimize. Some of the peephole and type-checker integration may already be implemented there. Although we don’t perform protocol related type optimizations and the Erlang compiler does not have enough information to do so, so maybe Elixir could/should.

Incremental compilation is ready

If you’re interested, you can try using Tria during development. Plus it is now completely safe to use Tria alongside vanilla elixir compiler

Not directly although some elements of the discussions have actually been implemented to some extent.

We did move some pure function evaluations to compile-time, see Inline functions in Elixir -> Erlang pass · Issue #13475 · elixir-lang/elixir · GitHub.
So for instance, if you write t = to_timeout(hour: 1, minute: 30), it will be compiled as t = 90000, just as if it was a macro.

Regarding comprehensions and the fact Enum.map was faster than for in some cases as discussed above in the thread.
We did change it so it compiles as Enum.map rather than Enum.reduce when it made sense (PR).

What we could do in Elixir itself is to keep a list of the functions in its standard library that are pure. Erlang also keeps a similar list for its standard library and inlines those. WDYT?

We can make this generally applicable but it is worth keeping in mind that each inlined modules becomes a compile-time dependency, and enlarging the compile time graphic can have huge impacts on performance. This is not a concern for Elixir stdlib itself though.

It is also not possible to know if something is pure or not when calling Erlang functions (unless we have an FFI layer where you also explicitly declare those).

Ah, thank you. We had a previous discussion about this. At the time, the cost of traversal in for comparing Enum.reduce vs Enum.map was roughly 13% faster. However, your benchmarks show the body recursive version can be even faster and we could emit Erlang AST with a body recursive version using Erlang’s “named anonymous functions”. Is this something you have an interest in contributing? Or should I open up an issue for someone else to pick?

I would argue it is fine for Elixir to work under the assumption its root modules are not being changed. After all, if you replace any Elixir module and change its behavior, then any part of Elixir may break.