Здравствуйте, SkyDance, Вы писали:

N>>Проблемы начинаются, если делается синхронный вызов. Каждый такой вызов это:
SD>Правильно. В первоначальном варианте языка никаких "синхронных вызовов" не предусматривалось (и правильно, по делу).

Ну и где этот "правильный вариант", если сейчас без gen_call OTP в принципе не будет работать — слишком много на него завязано?
Может, вместо того, чтобы его ругать, просто набраться сил и признаться, что синхронные вызовы неизбежны и надо с ними справляться?

N>>Это оптимизация на частный случай, и она сделана, кажется, в 14-м релизе

SD>А сейчас на дворе 23.
SD>И оптимизации сделаны чуть иначе, с чуть большими возможностями. Но, да, только под конкретный шаблон (тот самый gen_server:call).

Вот в этом и загвоздка.

SD>Странно еще что вы не совершили традиционный "удар ниже пояса" на тему monitor()/demonitor() — ведь это еще пара злобных поглотителей времени (и да, конечно, уже тоже давно не относится к реальности, примерно с R21, где было добавлено то самое, о чем вы просили — "две очереди", даже, скажем так три, но не для пользователя).

Потому что monitor/demonitor был ближе к константной затрате на каждый вызов (хотя при перегруженных линках и он мог давать сверхлинейные затраты по времени, но этого я уже тупо не помню).

SD>Вот именно это меня особенно смущает, "подтверждение экспериментами". Нет бы просто прочитать код и разобраться. Как это сделали мы.

Как чтение кода давало бы понять, упёрлись в кэширование или нет? Не заговаривайтесь.