I see that Phoenix (lib/phoenix.ex lines 38/39) warms up the template engines. From what I can understand, it checks if [:phoenix, :compiled_template_engines] is defined, and if it is not defined it defines it and returns its value. So the application environment is being used a state store. Why is this done this way and not with agents?
The app env is using an ets table optimized for concurrent reads, while an agent (as any single process) cannot do work concurrently. So using an agent would result in worse performance under load.
2 Likes
Oh yeah, so you mean, this is an optimization relative to using the agent abstraction for holding state is all?
ETS tables are more fundamental to the BEAM than Agents. I honestly can’t really think of any reason to use an Agent instead of ETS except for beginner tutorials.
1 Like
Interesting, I did some (very fun!) code spelunking and here it is.
Application.get_env ultimately ends up reading an ETS table:
get_env(AppName, Key) ->
case ets:lookup(ac_tab, {env, AppName, Key}) of
[{_, Val}] -> {ok, Val};
_ -> undefined
end.
Nice =D
