I’m still a little confused what this project is/does.

Can you try to restate what it is and what it does in simpler terms?

“Optimizer” means a thing which makes something more efficient.

So is Tria. It simply makes your code more efficient in terms of time and memory when you add it to your project as a dependency (and a list of compilers). It makes Enum calls and for loops faster, it removes unnecessary calls, it evaluates some stuff in compile time

This is very exciting! Looking forward to testing this on some projects.

Tiny question: In the install guide you add {:tria, github: "hissssst/tria"} to the deps, presumably this could be runtime: false or does it need to exist when the app runs too?

No, Tria is not called in runtime, though I haven’t testing it with this flag yet. To be honest, I’ve only tested it with path: "../tria" during development

Ahh, so bad we can’t set compilers via Mix.install/2 (we can only turn off consolidated protocols) … Is there any particular reason why thee is no support for it?

I think we can create a proposal for the language. I don’t see any boundaries why this shouldn’t be implemented there

I was thinking the same, but your comment made me sure about it. Here is in issue:
https://github.com/elixir-lang/elixir/issues/12349

As wrote in it once there would be a support for it at least in main branch I would try your library with my scripts like scrapers and I would try to submit some benchmarks as well.

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.

Thanks for your questions!

This is a big questions. Generally, there are two types of functions: functions which are defined in Erlang or Elixir, or functions which are undefined (thus contain erlang:nif_error or call to themselves in their bodies like in Elixir bootstrap).

For the latter, I’ve prepared the ets table file with purity for all such function from all available modules. When unexpected NIF function is found in call stack, Tria would just ask the user in TTY if such function is pure. I have a plan to add annotations like

@tria pure: true, safe: true
def my_nif() do
  ...
end

For the functions which have Erlang/Elixir definitions, compiler fetches the abstract code, translates it to Tria and just takes a look at all possible calls. So, calls to impure or anonymous functions are considered impure and this is not always correct, but it works for the first iteration of compiler and it can be partially solved with type checking in the future

It translates Enum.reduce() |> :lists.reverse to Enum.map. Compiler just needs to make sure that Enum.reduce aggregates each item straight to the accumulator list, without any conditions. Here’s the optimization: tria/lib/tria/optimizer/pass/enum_fusion.ex at main · hissssst/tria · GitHub. You can see there tri macro which is a great tool for pattern-matching on Tria AST.

It will be different in some ways. For example, inter-module calls will be inlined. And defaults (like foo(x, y \\ 0) will be expanded too, removing one call in the stack

However, some of these approaches change the behaviour of the program in two ways:

1. Pure code which raises exceptions may be reordered by EnumFusion optimization. I am working on fixing this behavior to have more correct compiler.
2. Runtime recompilation is not yet possible. It can be possible in the future, but Tria just needs some tooling for this.

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?