DLRでの不要なボクシングの回避
-
06-07-2019 - |
質問
DLRをよりよく理解するために遊んでいます。私はまだそのすべての概念とその用語に完全には精通していません。私の質問の用語や概念の間違いについては申し訳ありません。
基本的に、私が理解しているのは、式ツリーでオブジェクトを渡すことですが、バインダーを使用してオブジェクトの動的機能を他のDLR対応言語に公開することです。したがって、たとえば式ツリーで直接(Expression.Addを使用して)追加を行う代わりに、必要なときに呼び出しサイトによって呼び出され、追加を行うバインダーを作成します。
ただし、オブジェクトを渡すため、加算操作の最後に(たとえば、オペランドが2つのInt32値である場合)、結果のInt32をオブジェクトにボックス化する必要があります(まだバインダー内にあるため)呼び出しサイトが期待するもの。このコンスタントなボクシング/アンボクシングは、ランタイムのパフォーマンスに多少影響するのではないかと少し心配しています。
これは実際に(すべてのボクシング/アンボクシングで)動作するはずなのか、何か不足していますか?
解決
動的に型付けされた言語では、静的に型付けされた変数の識別と最適化は、ドメイン固有の最適化です。特定の動的言語Xの実装内では、生成されたコードにボックス化されていないローカル変数を保持できますが、動的に型指定されたAPIを公開するとすぐに、静的型付け(動的言語の本質)を保証する方法はありません。
ボックス化を回避するには、全体にわたって静的型を証明できるコードの一部を識別し、特に Linq.Expressions
または ILGenerator
。
他のヒント
バインダーについては、カスタムバインダーを実装することもできます。そのカスタムバインダーは、非オブジェクトタイプを返すか、他の特定の最適化を行うことができます。 IronPythonでは、条件を最適化するために、DLRの外部層ComboBinderとComboActionRewriterを使用します。たとえば、" if a.b:" a.bとboolへの変換の両方を行うComboBinderに変換できます。 a.bがボックス化されていないboolになる場合、ボックス化とボックス化解除を回避します。このようなさらなる最適化の実験を計画しています。