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?
mdnowack
mat-hek
Membrane Core Team
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.
3
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.
Right now Tria is incompatible with Patch. But I don’t know what Jose’s plans about inlining and compile time evaluation are.
1
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)
4
hst337
Incremental compilation is ready
Schultzer
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.
0
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.
2
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).
8