Ape*_*ron 5 .net performance garbage-collection
在我的工作中,我们正在讨论清理大量托管的~50-100MB内存的不同方法.桌面上有两种方法(阅读:两位资深开发人员不能同意)并没有经验其余的团队不确定哪种方法更可取,性能或可维护性.
收集的数据是许多小项目,约30000,其中包含其他项目,所有对象都被管理.这些对象之间有很多引用,包括事件处理程序,但不包括外部对象.我们将这一大组对象和引用称为一个名为blob的实体.
方法#1:确保切断对blob中对象的所有引用,并让GC处理blob和所有连接.
方法#2:在这些对象上实现IDisposable,然后对这些对象调用dispose并设置对Nothing的引用并删除处理程序.
第二种方法背后的理论是因为较长寿命的对象需要更长的时间来清理GC.因此,通过将大型物体切割成更小的一口大小,垃圾收集器将更快地处理它们,从而提高性能.
所以我认为基本的问题是:拆分大量互连对象是否优化了垃圾收集数据,或者最好将它们保持在一起并依靠垃圾收集算法为您处理数据？
我觉得这是一个预优化的案例,但我不知道GC是否足以知道它有什么帮助或阻碍它.
编辑:要强调内存的"blob"不是单个大对象,它是分开分配的许多小对象.
更多背景,以防有用.我们有'泄漏',因为对象没有得到GCed.这两种方法都解决了泄漏问题,但在这一点上,这是一个更合适的辩论.
第二种方法是错误的 - 它假定实施IDisposable将影响垃圾收集器.
不幸的是,IDisposable与垃圾收集无关.它纯粹是关于释放非托管资源.听起来你的第二个高级开发人员试图为自己的利益做一点"太聪明".
第一种方法应该没问题.一旦停止引用"blob",博客中的每个对象都将无根,并且应该被清除.这可能在您发布引用后的某个不确定时间发生(除非您明确告知GC要收集,我不建议这样做).将为您正确处理相互依赖性.
假设从理论上讲,实现IDisposable和清理内部引用可以加快收集过程.如果有(小)净收益,那么处理所有数据所花费的时间很可能超过GC中的任何收益 - 而且它实际上超出了您的业务关注范围.
但是,我怀疑它实际上会减慢整个垃圾收集器的速度,而不是加速它.将数据集分解为大量对象无助于GC运行得更快 - 它仍然需要跟踪实时引用,这在这种情况下没有什么不同.
| 归档时间： |
|
| 查看次数： |
455 次 |
| 最近记录： |