Избегайте ненужного бокса в DLR

Question

Я играю с DLR, чтобы лучше понять его. Я еще не полностью знаком со всеми его концепциями и терминологией, поэтому я сожалею о любых терминологических или концептуальных ошибках в моем вопросе.

В принципе, я понимаю, что вы передаете объекты в деревьях выражений, но вы используете связующие, чтобы подвергать динамические функции объектов другим языкам, поддерживающим DLR. Поэтому вместо того, чтобы делать добавление, например, непосредственно в дереве выражений (с помощью Expression.Add), вы создаете связующее, которое вызывается сайтом вызова всякий раз, когда это необходимо, и делает это для вас.

Однако, поскольку вы передаете объекты вокруг, в конце операции добавления (если операндами являются, например, два значения Int32), вам придется привязать полученный Int32 к объекту, поскольку (все еще в связующем) это то, что ожидает сайт вызова. Я немного боюсь, что этот постоянный бокс/распаковка может несколько повлиять на производительность среды выполнения.

Действительно ли это так, как предполагается работать (со всем боксом/распаковкой), или я что-то упускаю?

Answer 1

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

Чтобы избежать бокса, вам нужно будет идентифицировать фрагменты кода, которые вы можете доказать статические типы повсюду, и сгенерировать код специально для них либо через Linq.Expressions, либо ILGenerator.

Answer 2

Что касается переплётов, вы также можете реализовать пользовательское связующее. Это настраиваемое связующее может либо возвращать не-объектный тип, либо выполнять другие конкретные оптимизации. В IronPython мы используем внешний слой DLR ComboBinder и ComboActionRewriter для оптимизации условных выражений. Например, «если a.b:» может превратиться в ComboBinder, который выполняет как a.b, так и преобразование в bool. Если a.b приводит к отсутствию бокса, мы избежим бокса и распаковки. Мы планируем экспериментировать с такими оптимизациями.