hst337

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 4182 32

2025-07-16 08:40:13 UTC

Showing Posts 32 to 23

Show Best Posts
Show All (oldest first)
Show All (newest first)

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 #32

Eiji

What I wanted to say is that v1.19 standalone have amazing optimisations and we are talking about 3 versions in total. I believe that in this field much more happen in Elixir core than this project offers. I’m not even sure if this package works without any problems on latest versions. Look how much changes was made also in Erlang. That’s why I believe that just being up-to-date is not only more stable, but most probably also much faster option.

It’s like:

v1.19 standalone > v1.16 with Tria > v1.16 standalone

not in specific type of optimisation, but in total. JSON from v1.18 standalone should be much more than enough for various big projects and we are talking about only one feature.

Post #31

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 #30

Schultzer

I believe that parallel compilation and the optimizations mentioned in this thread are different.

const evaluation.
module inlining (AFAIK, BEAM can’t cross module inline functions).
fused enum.

Post #29

Eiji

Looking at GitHub repository the last commit fixes tests for v1.15 and v1.16 versions of Elixir and it was send over a year ago. There is still a note warning saying that Tria is unstable and may break a code. Regardless if it works or not it’s most likely not a good idea to use it anywhere close to production and I believe that Elixir core team made various optimisations since last Tria commit, so we either way would not feel much change especially if we have enabled parallel compilation in latest release candidate which is truly amazing.

Post #28

Schultzer

Hey, did any of this amazing work ever end up in Elixir?

Post #27

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 #26

hst337

By the way, does anyone know how to compile Elixir module without generating warnings?

Post #25

hst337

I am very pleased to hear that

That’s might be true, since this is the first iteration of compiler and I’ve implemented just some basic optimizations so far. You can expect something benchmarkable after the second iteration.

And, as far as I know, membrane’s code is already idiomatic and performance-tuned, so there is almost no space for current low-hanging-fruit optimizations I’ve implemented.

Yes, that’s true, right now Tria compiles whole project into single module. This approach insignificantly reduces function call overhead and gives more space for Erlang’s inlining optimization pass.

I’ve already implemented some logic which allows to compile Tria into several combined modules (instead of big and huge one)

Post #24

hst337

I think the most important thing here is change its behaviour. Some tests may only check if something was called and what arguments were passed to it.