Avoiding unnecessary boxing in DLR

Question

I'm playing with DLR to get a better understanding of it. I'm not completely familiar yet with all its concepts and its terminology so sorry for any terminological or conceptual mistakes in my question.

Basically, the way I understand it is that you pass around objects in expression trees but you use binders in order to expose your objects' dynamic functionality to other DLR-aware languages. So instead of doing an addition, for example, directly in the expression tree (With Expression.Add), you create a binder that is invoked by the call site whenever it is needed and does the addition for you.

However, since you pass objects around, at the end of the addition operation (if the operands are, for example, two Int32 values) you will have to box the resulting Int32 to an object since (still in the binder) that what the call site expects. I'm a bit afraid that this constant boxing / unboxing might affect the performance of the runtime somewhat.

Is this really how it is supposed to work (with all the boxing / unboxing) or am I missing something?

Answer 1

In a dynamically-typed language, the identification and optimization of a statically-typed variable is a domain specific optimization. Within a particular dynamic language X's implementation, you could keep an unboxed local variable in generated code, but as soon as you expose a dynamically-typed API, there's no way to guarantee static typing (the very nature of dynamic languages).

To avoid boxing, you'll have to identify pieces of code that you can prove static types throughout, and generate code especially for them either through Linq.Expressions or ILGenerator.

Answer 2

As far as the binders go you can also implement a custom binder. That custom binder can either return a non-object type or can do other specific optimizations. In IronPython we ues the DLR outer layer ComboBinder and ComboActionRewriter to optimize conditionals. For example "if a.b:" can turn into a ComboBinder which does both the a.b and the conversion to bool. If a.b results in a non-boxed bool we will avoid the boxing and unboxing. We plan on experimenting on more optimizations like this.