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.
6 Likes
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?
2 Likes
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 Likes
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 Like
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 Likes
By the way, does anyone know how to compile Elixir module without generating warnings?
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
10 Likes
Hey, did any of this amazing work ever end up in Elixir?
1 Like
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.
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 Likes
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 Likes
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.
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.
1 Like
