а вот еще по поводу конфигов и идиом - как ловчее перейти от hard-coded значений к каким-то конфигурационным

case expression of 
  hard_coded_atom -> 
case expression of 
  Result when is_soft_coded_atom ->

(ну кроме переписывания кода)

не давать пользователю ручками что-либо настраивать?)

Я про своё — с динамически скомпилированным модулем

Вот тоже согласен. Быстрее persistent_term только этот вариант

это не для пользователя настройка скорее, а глобальная для проекта. что-то вроде директивы пропроцессора в сишечке

А если что-то вроде этого - то прирост 1.5-3 раза. Т.к в persistent_term придется в качестве ключа туплы хранить.
env(namespace1, property1) -> value1;
env(namespace1, property2) -> value2;
env(_, property1) -> default1;
env(_, property2) -> default2;
env(_, _) -> undefined.

Без реальных замеров это всё разговоры в пользу бедных.
В моем случае речь идёт о десятках запросов к конфигам в секунду. И всё это если даже экономит пару микросекунд, опять же в данном проекте совершенно не нужно.
В моём представлении об идеальном мире люди городят такой самописный колхоз в проде только если плюсы от этого перевешивают минусы.
В данном случае мизерная экономия не нужна, и я пытаюсь понять: может, я что-то ещё упускаю...

Если мизерная экономия не нужна, то persistent_term пойдёт конечно. Основной минус динамического компайла - медленный старт

а есть пример такой компиляции?

Да

ссылка. может еще есть примеры костылей и идиом - вроде глобального макроса (без включения хидеров) или реализация функции для guard

Да может для кого-то это стандартный вариант работы с конфигами. Всегда так делает, что 10000 запросов в секунду, что десятки. просто стандартный шаблон

просто чтобы не заморачиваться

тем более это не так сложно, один раз написал компилятор который по декларации параметров конфига и их типам геренрирует модуль с функциями и используешь во всех проектах

Ну вот я в своём проекте это заюзал. Это фактически mochiglobal, только малость пропатченный

https://github.com/DOBRO/binbo/blob/master/src/binbo_global.erl

у меня что-о типа такого
Funs = [
   {mnesia_dir, 0, MnesiaDir, string},
   {apiip, 0, APIIP, term},
   {statapiip, 0, StatAPIIP, term},
   {reverse_proxy_ip, 0, RevProxyIPs, term},
   {random_ip, 0, RandomIP, atom},
   {brand, 0, Brand, atom},
   {reverse_proxy, 0, ReverseProxy, atom},
   {inroute, 0, InROute, string},
   {blockpost,  0, BlockPost, boolean},
   {admin_log_enabled,  0, AdminLogEnabled, atom},
   {startunix, 0, StartUnix, integer},
   {startunixbin, 0, integer_to_binary(StartUnix), binary}
 ],


make_module(ModuleName, Funs) ->
 Module = erl_syntax:attribute(erl_syntax:atom(module), [erl_syntax:atom(ModuleName)]),
 ModForm = erl_syntax:revert(Module),

 Export = erl_syntax:attribute(
   erl_syntax:atom(export), [
     erl_syntax:list(
       [erl_syntax:arity_qualifier(erl_syntax:atom(FunName), erl_syntax:integer(Arity)) || {FunName, Arity, _, _} <- Funs]

     )
   ]
 ),
 ExportForm = erl_syntax:revert(Export),

 FunsAst = lists:foldl(
   fun(FunRec, Acc) ->
     [make_fun_ast(FunRec) | Acc]
   end,
   [],
   Funs
 ),

 {ok, Mod, Bin1} = compile:forms([ModForm, ExportForm | FunsAst]),
 {module, _} = code:load_binary(Mod, [], Bin1),
 ok.

аа, такое. ну это мало отличается от persistent_term по семантике
а  мне нужна глобальная константа, которую можно применять в guards, ну или возможность расширить guards functions

можно динамически генерить модуль с guards functions и так далее. но это геморрой если делать универсально

а так дял каких-то отдельных маленьких функций не так сложно

ну вот в коде куча мест где используется atom, теперь case где этот атом надо переделать.
для этого надо городить код с динамическими проверками или же
там где раньше был атом  добавить guard всравнения с константой , но для этого
надо создавать хидер и его инклудить..  почему они не разрешили создавать свои guard функции без побочных эффектов?