hst337

Tria - the Elixir optimizer

Tria

An optimizing compiler for Elixir language

Public and alpha

I’ve made this repository public to finally get some rest and find other developers who may be interested in participating in this project (it sounds so naive when I write it) before getting hands on the second iteration.

Current state

!!!Unstable!!!

Tria passes most of the tests in Phoenix, Ecto, Plug and other projects, while it may fail to compile other projects. You’re welcome to compile projects using Tria and fill an issue if something fails. This kind of help would be heavily appreciated.

Even without considering this, Tria compiler lacks some important features like incremental compilation, warning handling and stuff.

However, you can expect the stable version during 2023-ish

Current features

Compile-time evaluation.
Yes, as simple as it sounds, Elixir and Erlang were incapable of doing this, since they support runtime recompilation. Ahead-of-time nature of Tria allowed to evaluate pure statement in compile time
Enum fusion
Join multiple Enum.maps, optimize for loops to finally be efficient and other magic.

I haven’t benchmarked these yet, but these optimizations actually work and (more importantly) work correctly in most cases

Planned features

Broad documentation (like pathex has)
Inlining
Hot-reloading support
Peephole optimizations for common suboptimal code.
map.field handling (did you know that it is 2-3 times slower than Map.fetch!(map, :field)?)
Type-checker integration

Help wanted

If you’re interested in optimizing compiler development, you’re welcome to take a look around, poke some things, check some stuff. I know that some Brazilian universities are working in Elixir-related compiler development, and I hope we can collaborate on Tria someday

PS: Questions are appreciated

UPD: License is going to change in a near future

32 comments

#library #optimization #tria

30 3773 32

2025-07-16 08:40:13 UTC

Most Liked

josevalim

Creator of Elixir

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.

Post #9

hst337

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

Post #27

sabiwara

Elixir Core Team

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).

Post #31

Last Post!

mat-hek

Membrane Core Team

I believe most of these optimisations could be applied in the Erlang compiler (that Elixir uses underneath) and in the BEAM, not in the Elixir core. Haven’t heard of them being introduced, unfortunately, but maybe I missed something.

Post #33