避免 DLR 中不必要的拳击

发布于 2024-08-08 13:14:45 字数 368 浏览 5 评论 0原文

我正在使用 DLR 来更好地理解它。我还不完全熟悉它的所有概念和术语,对于我的问题中的任何术语或概念错误,我深表歉意。

基本上,我的理解是,您在表达式树中传递对象,但使用绑定器以便将对象的动态功能公开给其他 DLR 感知语言。因此,您不必直接在表达式树中(使用 Expression.Add)进行添加,而是创建一个绑定器,调用站点会在需要时调用该绑定器并为您执行添加操作。

但是,由于您传递对象,因此在加法操作结束时(例如,如果操作数是两个 Int32 值),您必须将生成的 Int32 装箱到一个对象,因为(仍在活页夹中)调用的内容网站预计。我有点担心这种不断的装箱/拆箱可能会在一定程度上影响运行时的性能。

这真的是它应该如何工作(所有装箱/拆箱)还是我错过了一些东西?

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?

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(2

作业与我同在 2024-08-15 13:14:45

在动态类型语言中,静态类型变量的识别和优化是特定于域的优化。在特定的动态语言 X 的实现中,您可以在生成的代码中保留未装箱的局部变量,但是一旦公开动态类型的 API,就无法保证静态类型(动态语言的本质)。

为了避免装箱,您必须识别可以在整个过程中证明静态类型的代码片段,并通过 Linq.ExpressionsILGenerator 专门为它们生成代码。

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.

滴情不沾 2024-08-15 13:14:45

就活页夹而言,您还可以实现自定义活页夹。该自定义绑定器可以返回非对象类型,也可以执行其他特定的优化。在IronPython中,我们使用DLR外层ComboBinder和ComboActionRewriter来优化条件。例如,“if ab:”可以变成一个 ComboBinder,它既执行 ab 又转换为 bool。如果 ab 产生非装箱 bool,我们将避免装箱和拆箱。我们计划尝试更多这样的优化。

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.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文