Improving Performance at Compile Time

The patterns we previously discussed are powerful and flexible, and they let us have fine-tuned control over testing interactions with external services. However, there’s still one principle we’re going against.We’re introducing a runtime call to decide which double to use in production code. That is, every time we call the rain?/2 function, we’ll call Application.get_env/3 (which is essentially a read from an ETS table) to get the double module we want to use.

In this case, the performance hit is negligible compared to the cost of the HTTP call to the API when running in production. However, we can imagine cases where we might want to shave off even the handful of microseconds it takes to read from the ETS table in Application.get_env/3.

compile_env/3

A good initial approach to solve the above problem is to read the module at compile time using Application.compile_env/3. The compile_env/3 function works like get_env/3, but enforces that it’s used at compile time and allows Elixir to track configuration values that change between runtime and compile time. We won’t focus on this feature in particular here, but it’s good practice using compile_env/3 in cases like this one.