Tria - the Elixir optimizer

[josevalim]

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.

[mdnowack]

Hi, author of Patch here, it does rely on recompiling modules but is really only for use at test time since it’s a testing library. Would these changes apply in that context as well?

[mat-hek]

Hi, thanks for the library Reporting that after some tweaking (reported issues via GH) I managed to compile membrane_core and run a video call based on it, and it worked though I haven’t noticed any performance impact so far.

I once had an idea for a tool that would merge some hot-path modules into a single module and hope that the compiler would be able to do more optimisations since there would be mostly local calls. Do I understand correctly that something like this is in the scope of Tria? Actually, tria_global_context seems like the entire codebase merged into a single module.

[hst337]

@josevalim

After all, if you replace any Elixir module and change its behavior, then any part of Elixir may break

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.

@mdnowack

Hi, author of Patch here, it does rely on recompiling modules but is really only for use at test time since it’s a testing library. Would these changes apply in that context as well?

Right now Tria is incompatible with Patch. But I don’t know what Jose’s plans about inlining and compile time evaluation are.

[hst337]

@mat-hek

reported issues via GH

@mat-hek

and it worked

I am very pleased to hear that

@mat-hek

though I haven’t noticed any performance impact so far

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.

@mat-hek

Do I understand correctly that something like this is in the scope of Tria?

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)

[hst337]

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

[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