В нашей компании мы активно используем Erlang, но часто рассматриваем другие альтернативные языки и подходы для улучшения качества собственного кода.
Elixir – это функциональный язык программирования общего назначения, который работает на виртуальной машине BeamVM. От Erlang отличается синтаксисом, более похожим на Ruby, и расширенными возможностями метапрограммирования.
В Elixir также существует замечательный механизм для полиморфизма под названием Protocols, но в Erlang нет синтаксической конструкции для динамической диспетчеризации, которая необходима для их реализации.
Тогда как же они устроены внутри? Какой overhead дает код с использованием протоколов? Попробуем разобраться.
Есть два способа понять, что происходит внутри:
– разобраться с тем, как Elixir Compiler генерирует код для BeamVM,
– декомпилировать beam-файлы и посмотреть, что же в итоге получилось.
Второй способ намного проще, воспользуемся им.
Для начала создадим новый проект.
mix new proto
cd protoТеперь отредактируем файл lib/proto.ex на довольно простой пример.
defprotocol Double do
def double(input)
end
defimpl Double, for: Integer do
def double(int) do
int * 2
end
end
defimpl Double, for: List do
def double(list) do
list ++ list
end
endТут мы объявили новый протокол Double с интерфейсом double/1 и две реализации этого протокола для Integer и List.
Проверим работоспособность:
iex(1)> Double.double(2)
4
iex(2)> Double.double([1,2,3])
[1, 2, 3, 1, 2, 3]
iex(3)> Double.double(:atom)
** (Protocol.UndefinedError) protocol Double not implemented for :atom
(proto) lib/proto.ex:1: Double.impl_for!/1
(proto) lib/proto.ex:2: Double.double/1
Теперь посмотрим на структуру скомпилированных файлов.
$ tree _build/dev/
_build/dev/
├── consolidated
│ ├── Elixir.Collectable.beam
│ ├── Elixir.Double.beam
│ ├── Elixir.Enumerable.beam
│ ├── Elixir.IEx.Info.beam
│ ├── Elixir.Inspect.beam
│ ├── Elixir.List.Chars.beam
│ └── Elixir.String.Chars.beam
└── lib
└── proto
└── ebin
├── Elixir.Double.beam
├── Elixir.Double.Integer.beam
├── Elixir.Double.List.beam
└── proto.appПервое, что бросается в глаза – наличие модулей с одинаковыми именами в consolidated- и lib/proto/ebin-директориях. Рассмотрим их содержимое.
Для начала beam-файлы нужно декомпилировать. Для этого создадим escript-файл beam_to_erl
#!/usr/bin/env escript
main([BeamFile]) ->
{ok,{_,[{abstract_code,{_,AC}}]}} = beam_lib:chunks(BeamFile,[abstract_code]),
io:fwrite("~s~n", [erl_prettypr:format(erl_syntax:form_list(AC))]).и пробежимся им по всем beam-файлам.
$ for f in $(find _build/ -name "*.beam"); do ./beam_to_erl $f > "${f%.beam}.erl"; done$ tree _build/dev/ | grep -v ".beam"
_build/dev/
├── consolidated
│ ├── Elixir.Collectable.erl
│ ├── Elixir.Double.erl
│ ├── Elixir.Enumerable.erl
│ ├── Elixir.IEx.Info.erl
│ ├── Elixir.Inspect.erl
│ ├── Elixir.List.Chars.erl
│ └── Elixir.String.Chars.erl
└── lib
└── proto
└── ebin
├── Elixir.Double.erl
├── Elixir.Double.Integer.erl
├── Elixir.Double.List.erl
└── proto.appРассмотрим содержимое файла lib/proto/ebin/Elixir.Double.erl.
-compile(no_auto_import).
-file("lib/proto.ex", 1).
-module('Elixir.Double').
-compile(debug_info).
-compile({inline,
[{any_impl_for, 0}, {struct_impl_for, 1},
{'impl_for?', 1}]}).
-protocol([{fallback_to_any, false}]).
-export_type([t/0]).
-type t() :: term().
-spec '__protocol__'('consolidated?') -> boolean();
(functions) -> [{double, 1}, ...];
(module) -> 'Elixir.Double'.
-spec impl_for(term()) -> atom() | nil.
-spec 'impl_for!'(term()) -> atom() | no_return().
-callback double(t()) -> term().
-export(['__info__'/1, '__protocol__'/1, double/1,
impl_for/1, 'impl_for!'/1]).
-spec '__info__'(attributes | compile | exports |
functions | macros | md5 | module |
native_addresses) -> atom() |
[{atom(), any()} |
{atom(), byte(), integer()}].
'__info__'(functions) ->
[{'__protocol__', 1}, {double, 1}, {impl_for, 1},
{'impl_for!', 1}];
'__info__'(macros) -> [];
'__info__'(info) ->
erlang:get_module_info('Elixir.Double', info).
'__protocol__'(module) -> 'Elixir.Double';
'__protocol__'(functions) -> [{double, 1}];
'__protocol__'('consolidated?') -> false.
any_impl_for() -> nil.
double(_@1) -> ('impl_for!'(_@1)):double(_@1).
impl_for(#{'__struct__' := _@1})
when erlang:is_atom(_@1) ->
struct_impl_for(_@1);
impl_for(_@1) when erlang:is_tuple(_@1) ->
case 'impl_for?'('Elixir.Double.Tuple') of
true -> 'Elixir.Double.Tuple':'__impl__'(target);
false -> any_impl_for()
end;
impl_for(_@1) when erlang:is_atom(_@1) ->
case 'impl_for?'('Elixir.Double.Atom') of
true -> 'Elixir.Double.Atom':'__impl__'(target);
false -> any_impl_for()
end;
impl_for(_@1) when erlang:is_list(_@1) ->
case 'impl_for?'('Elixir.Double.List') of
true -> 'Elixir.Double.List':'__impl__'(target);
false -> any_impl_for()
end;
impl_for(_@1) when erlang:is_map(_@1) ->
case 'impl_for?'('Elixir.Double.Map') of
true -> 'Elixir.Double.Map':'__impl__'(target);
false -> any_impl_for()
end;
impl_for(_@1) when erlang:is_bitstring(_@1) ->
case 'impl_for?'('Elixir.Double.BitString') of
true -> 'Elixir.Double.BitString':'__impl__'(target);
false -> any_impl_for()
end;
impl_for(_@1) when erlang:is_integer(_@1) ->
case 'impl_for?'('Elixir.Double.Integer') of
true -> 'Elixir.Double.Integer':'__impl__'(target);
false -> any_impl_for()
end;
impl_for(_@1) when erlang:is_float(_@1) ->
case 'impl_for?'('Elixir.Double.Float') of
true -> 'Elixir.Double.Float':'__impl__'(target);
false -> any_impl_for()
end;
impl_for(_@1) when erlang:is_function(_@1) ->
case 'impl_for?'('Elixir.Double.Function') of
true -> 'Elixir.Double.Function':'__impl__'(target);
false -> any_impl_for()
end;
impl_for(_@1) when erlang:is_pid(_@1) ->
case 'impl_for?'('Elixir.Double.PID') of
true -> 'Elixir.Double.PID':'__impl__'(target);
false -> any_impl_for()
end;
impl_for(_@1) when erlang:is_port(_@1) ->
case 'impl_for?'('Elixir.Double.Port') of
true -> 'Elixir.Double.Port':'__impl__'(target);
false -> any_impl_for()
end;
impl_for(_@1) when erlang:is_reference(_@1) ->
case 'impl_for?'('Elixir.Double.Reference') of
true -> 'Elixir.Double.Reference':'__impl__'(target);
false -> any_impl_for()
end;
impl_for(_) -> any_impl_for().
'impl_for!'(_@1) ->
case impl_for(_@1) of
_@2 when (_@2 =:= nil) or (_@2 =:= false) ->
erlang:error('Elixir.Protocol.UndefinedError':exception([{protocol,
'Elixir.Double'},
{value,
_@1}]));
_@3 -> _@3
end.
'impl_for?'(_@1) ->
case 'Elixir.Code':'ensure_compiled?'(_@1) of
true ->
'Elixir.Kernel':'function_exported?'(_@1, '__impl__',
1);
false -> false;
_@2 -> erlang:error({badbool, 'and', _@2})
end.
struct_impl_for(_@1) ->
_@2 = 'Elixir.Module':concat('Elixir.Double', _@1),
case 'impl_for?'(_@2) of
true -> _@2:'__impl__'(target);
false -> any_impl_for()
end.А вот и вся магия. Давайте взглянем на функцию double/1.
double(_@1) -> ('impl_for!'(_@1)):double(_@1).Она ищет модуль, который подходит для передаваемого аргумента, через impl_for/1 и вызывает его реализацию.
А как найти модуль для аргумента? Очень просто:
– если это примитив или bif-тип, то просто ищем модуль с именем 'Elixir.{ProtocolName}.{TypeName}', где ProtocolName – имя протокола, TypeName – имя типа. Подгружем его, если еще не загружен, через 'Elixir.Code':'ensure_compiled?'/1. Проверяем, является ли модуль реализацией протокола через наличие функции '__impl__'/1, и получаем модуль реализации '__impl__'(target),
– если это структура, то смотрим на служебное поле __struct__ и таким же образом ищем модуль 'Elixir.{ProtocolName}.{StructName}',
– если реализация не найдена, проверяем наличие реализации по умолчанию для any-типа или возвращаем ошибку.
Реализация протокола же остается практически в неизменном виде. Добавляется лишь несколько системных функций. Например: 'Elixir.Double.Integer'.
-compile(no_auto_import).
-file("lib/proto.ex", 5).
-module('Elixir.Double.Integer').
-behaviour('Elixir.Double').
-impl([{protocol, 'Elixir.Double'},
{for, 'Elixir.Integer'}]).
-spec '__impl__'(protocol) -> 'Elixir.Double';
(target) -> 'Elixir.Double.Integer';
(for) -> 'Elixir.Integer'.
-export(['__impl__'/1, '__info__'/1, double/1]).
-spec '__info__'(attributes | compile | exports |
functions | macros | md5 | module |
native_addresses) -> atom() |
[{atom(), any()} |
{atom(), byte(), integer()}].
'__info__'(functions) -> [{'__impl__', 1}, {double, 1}];
'__info__'(macros) -> [];
'__info__'(info) ->
erlang:get_module_info('Elixir.Double.Integer', info).
'__impl__'(for) -> 'Elixir.Integer';
'__impl__'(target) -> 'Elixir.Double.Integer';
'__impl__'(protocol) -> 'Elixir.Double'.
double(int@1) -> int@1 * 2.Другими словами, вся динамическая диспетчеризация сводится к поиску модуля по имени, зная алгоритм составления этого имени для реализации протокола. У такого подхода есть один несущественный минус – вы не можете определить несколько реализаций протокола для одного и того же типа.
Overhead при этом оказывается не таким уж и маленьким, особенно для высоконагруженных систем. Дело в постоянной проверке наличия модуля в runtime.
Для устранения этого недостатка была добавлена возможность «зашить» роутинг для известных на этапе компиляции реализаций протокола непосредственно в функцию диспетчеризации impl_for/1
Эта функция компилятора называется consolidated protocols и с Elixir v1.2 осуществляется автоматически во время сборки релиза через mix.
Взглянем на consolidated/Elixir.Double.erl.
-compile(no_auto_import).
-file("lib/proto.ex", 1).
-module('Elixir.Double').
-compile(debug_info).
-compile({inline,
[{any_impl_for, 0}, {struct_impl_for, 1},
{'impl_for?', 1}]}).
-protocol([{fallback_to_any, false}]).
-export_type([t/0]).
-type t() :: term().
-spec '__protocol__'('consolidated?') -> boolean();
(functions) -> [{double, 1}, ...];
(module) -> 'Elixir.Double'.
-spec impl_for(term()) -> atom() | nil.
-spec 'impl_for!'(term()) -> atom() | no_return().
-callback double(t()) -> term().
-export(['__info__'/1, '__protocol__'/1, double/1,
impl_for/1, 'impl_for!'/1]).
-spec '__info__'(attributes | compile | exports |
functions | macros | md5 | module |
native_addresses) -> atom() |
[{atom(), any()} |
{atom(), byte(), integer()}].
'__info__'(functions) ->
[{'__protocol__', 1}, {double, 1}, {impl_for, 1},
{'impl_for!', 1}];
'__info__'(macros) -> [];
'__info__'(info) ->
erlang:get_module_info('Elixir.Double', info).
'__protocol__'(module) -> 'Elixir.Double';
'__protocol__'(functions) -> [{double, 1}];
'__protocol__'('consolidated?') -> true.
any_impl_for() -> nil.
double(_@1) -> ('impl_for!'(_@1)):double(_@1).
impl_for(#{'__struct__' := x}) when erlang:is_atom(x) ->
struct_impl_for(x);
impl_for(x) when erlang:is_list(x) ->
'Elixir.Double.List';
impl_for(x) when erlang:is_integer(x) ->
'Elixir.Double.Integer';
impl_for(_) -> nil.
'impl_for!'(_@1) ->
case impl_for(_@1) of
_@2 when (_@2 =:= nil) or (_@2 =:= false) ->
erlang:error('Elixir.Protocol.UndefinedError':exception([{protocol,
'Elixir.Double'},
{value,
_@1}]));
_@3 -> _@3
end.
'impl_for?'(_@1) ->
case 'Elixir.Code':'ensure_compiled?'(_@1) of
true ->
'Elixir.Kernel':'function_exported?'(_@1, '__impl__',
1);
false -> false;
_@2 -> erlang:error({badbool, 'and', _@2})
end.
struct_impl_for(_) -> nil.Код модуля существенно меньше оригинала и, что немаловажно, impl_for отрабатывает в один шаг без проверки наличия модуля.
Итого
Иногда полезно взглянуть изнутри на то, как работает инструмент. Это дает нам возможность лучше понять его преимущества и недостатки.
Реализация протоколов же довольно проста и при использовании consolidated protocols дает незначительный overhead, предоставляя при этом хорошую абстракцию над структурами данных. Тем не менее аналогичный механизм можно легко добавить и в Erlang, но это потребует ручного написания функции динамической диспетчеризации.
Использовать Elixir или нет – выбор за вами. Но мы пока остаемся на Erlang.
Автор: egobrain
