使用委托创建垃圾

我正在使用XNA为xbox360开发游戏。 在Xbox上,与PC上的垃圾收集器相比,垃圾收集器的性能相当差,因此将生成的垃圾保持在最低限度对于顺畅执行游戏至关重要。

我记得读过一次调用委托创建垃圾,但现在我的生活中找不到任何对委托创建垃圾的引用。 我是刚刚做到这一点还是代表们搞乱了?

如果代表是凌乱的,建议解决方法的奖励积分。

public delegate T GetValue(T value, T[] args); public static T Transaction(GetValue calculate, ref T value, params T[] args) where T : class { T newValue = calculate(value, args); return foo(newValue); } 

我的代码看起来模糊不清,目前,我能想到摆脱委托的唯一解决方案是传入一个inheritance了接口IValueCalculator的类,然后我可以在该接口上调用该方法,这不是很整洁虽然!

委托本身就是一个对象,所以如果你创建一个委托,也许是为了一个匿名方法,并将其赋予其他一些方法来执行,并且不存储委托以供将来参考,那么是的, 将产生垃圾。

例如,这个:

 collection.ForEach(delegate(T item) { // do something with item }); 

在这种情况下,会创建一个新的委托对象,但是除了对ForEach的调用之外,它没有被引用,因此有资格进行垃圾回收。

但是, 调用委托本身不会产生垃圾,而是调用相同类型的任何其他方法。 例如,如果你调用一个带有Object参数的委托,传入一个Int32值,这个值将被装箱,但是如果你也以同样的方式调用普通方法,那就会发生这种情况。

因此,使用委托应该没问题,但是过多创建委托对象将是一个问题。


编辑 :关于Xbox和XNA的内存管理的一篇很好的文章在这里: Xbox 360 for XNA上的托管代码性能:第2部分 – GC和工具 。 注意这个引用:

那么如何控制GC延迟呢? 与设备的NetCF一样,Xbox GC是非代数的。 这意味着每个集合都是托管堆上的完整集合。 因此,我们发现GC延迟与活动对象的数量大致呈线性关系……然后将堆压缩的成本添加到其上。 我们的基准测试表明深层对象层次结构与浅层对象层次结构之间的差异可以忽略不计,因此它主要是重要的对象数量。 与大型物体相比,小物体的处理成本也更低。

正如您所看到的,尽量避免创建大量不必要的对象,您应该做得更好。

在桌面环境中, 垃圾实际上是免费的 。 你想要担心的是你生产了多少非垃圾 。 记住垃圾收集器的工作原理:它首先标记所有已知对象,然后清除所有活动对象上的标记并压缩活动对象。 那里昂贵的一步是“取消标记活体对象”。 摧毁垃圾很便宜; 它识别昂贵的实时对象,并且成本取决于您拥有的活动对象的数量(以及它们的参考拓扑的复杂性),而不是您拥有的死对象的数量。

但是,在XBOX和其他紧凑的框架上,垃圾收集器运行频繁并且在创建新分配时运行得更频繁,所以是的,您也可以担心创建垃圾。 您希望将实时集保持为较小(以便使集合便宜)并且不进行新分配(因为这会触发集合。)

创建委托确实会分配内存,但调用一个只不过是在一个类上调用一个名为Invoke的方法。 委托只不过是一个带有名为Invoke的方法的类,它在调用时会立即调用另一个方法。

无论如何,如果你的内存性能有问题,那么正确的做法是拿出内存分析器并用它来分析你的程序。 随意投掷,想知道这个或那个是否分配记忆就像试图用指甲剪掉你的花园; 这需要花费很多时间,并没有真正实现你的目标。 使用分析器分析您的性能并查看问题所在,然后进行修复。

其他人已经注意到,代理创建会产生垃圾。

在您的示例中,使用params参数可能也会生成垃圾。

考虑在不使用params关键字的情况下提供重载。

这就是为什么库方法中通常存在具有不同数量的参数的重载以及使用params关键字的重载的原因:

请参见String.Format方法(String,Object [])

 Format Method (String, Object) Format Method (String, Object[]) ... Format Method (String, Object, Object) Format Method (String, Object, Object, Object)