Functionality that can only ever be used at compile time

[Zach Daniel]

Hey all! This isn't a fully fleshed out idea, but something that I've noticed especially with Ash Framework is how a *large* portion of our code should only ever be called when compiling.

What brought this to my attention recently is that there are tons of places where we may do things like convert strings to atoms (not using `to_existing_atom`), and currently we just tell sobelow to skip that behavior because we know its only used at compile time.

I'm aware that new code can be compiled at runtime, but my thought is that we can also potentially, on an opt-in basis, allow users to omit this compile time only code from their application, if they are *not* doing that. With how much code exists in Ash that serves only the compile time, I'm thinking this could significantly shrink the size of the code and its base memory footprint.

I don't know if the juice would be worth the squeeze here or not, and its also very possible that there are reasons why, even if we wanted to, we couldn't do this kind of thing

[José Valim]

My general gut feeling is: compared to the amount of code in Erlang/OTP, Elixir, dependencies, and the code that Ash generates, the amount of code in Ash used for code generation is going to be minimal. And all of that to save memory on a box that most likely still needs to load hundreds of rows from a database concurrently.

If you really believe this is worth it, then the quickest way to explore/achieve this is by having a separate package that you won't include in releases. It will be available for compilation, but not runtime.

--
You received this message because you are subscribed to the Google Groups "elixir-lang-core" group.
To unsubscribe from this group and stop receiving emails from it, send an email to elixir-lang-co...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/elixir-lang-core/5e1a0a22-e47a-4595-9ed3-d0a331552251n%40googlegroups.com.

[Zach Daniel]

Its hard to say. I was mostly curious to get some initial thoughts, but I'm also wondering if annotations for "only used when compiling code" could be used in elixir and Erlang core theoretically, even further decreasing the size (and memory footprint) of apps that don't need to dynamically compile code. But I'm sure its not worth it to invest the time/energy in that at this point. But in the future I might see if there is a way to identify just how much memory savings there would be and if there would be any other benefits (maybe app start time since less code to load?). Those metrics can add up in some situations.

On Thu, Feb 01, 2024 at 2:19 PM, José Valim <jose....@dashbit.co> wrote:

My general gut feeling is: compared to the amount of code in Erlang/OTP, Elixir, dependencies, and the code that Ash generates, the amount of code in Ash used for code generation is going to be minimal. And all of that to save memory on a box that most likely still needs to load hundreds of rows from a database concurrently.

If you really believe this is worth it, then the quickest way to explore/achieve this is by having a separate package that you won't include in releases. It will be available for compilation, but not runtime.

On Thu, Feb 1, 2024 at 7:16 PM Zach Daniel <zachary.s.daniel@gmail.com> wrote:

Hey all! This isn't a fully fleshed out idea, but something that I've noticed especially with Ash Framework is how a *large* portion of our code should only ever be called when compiling.

What brought this to my attention recently is that there are tons of places where we may do things like convert strings to atoms (not using `to_existing_atom`), and currently we just tell sobelow to skip that behavior because we know its only used at compile time.

I'm aware that new code can be compiled at runtime, but my thought is that we can also potentially, on an opt-in basis, allow users to omit this compile time only code from their application, if they are *not* doing that. With how much code exists in Ash that serves only the compile time, I'm thinking this could significantly shrink the size of the code and its base memory footprint.

I don't know if the juice would be worth the squeeze here or not, and its also very possible that there are reasons why, even if we wanted to, we couldn't do this kind of thing

--
You received this message because you are subscribed to the Google Groups "elixir-lang-core" group.

To unsubscribe from this group and stop receiving emails from it, send an email to elixir-lang-core+unsubscribe@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/elixir-lang-core/5e1a0a22-e47a-4595-9ed3-d0a331552251n%40googlegroups.com.

--

You received this message because you are subscribed to the Google Groups "elixir-lang-core" group.

To unsubscribe from this group and stop receiving emails from it, send an email to elixir-lang-core+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/elixir-lang-core/CAGnRm4JerLxvP1FU3wxT8N4p4yVWs-x3mo42eP5xS_4pjmchgQ%40mail.gmail.com.

[Zach Daniel]

That's aside from the "I don't want users to call this because it unsafely creates atoms", which isn't actually a problem I currently have now, as its usually pretty obvious what code is for compile time use and what isn't.

On Mon, Feb 05, 2024 at 1:10 PM, Zach Daniel <zachary....@gmail.com> wrote:

Its hard to say. I was mostly curious to get some initial thoughts, but I'm also wondering if annotations for "only used when compiling code" could be used in elixir and Erlang core theoretically, even further decreasing the size (and memory footprint) of apps that don't need to dynamically compile code. But I'm sure its not worth it to invest the time/energy in that at this point. But in the future I might see if there is a way to identify just how much memory savings there would be and if there would be any other benefits (maybe app start time since less code to load?). Those metrics can add up in some situations.