.NET 内存分析器优化收益在生产中消失答案

【问题标题】：.NET Memory profiler optimization gains disappear in production.NET 内存分析器优化收益在生产中消失
【发布时间】：2012-01-03 15:38:40
【问题描述】：

我一直在使用内存分析器（来自 Scitech 的 .NET Memory Profiler），仔细检查各种代码，并改进我的程序的垃圾生成特性。计数器显示垃圾收集已大大减少。

或者看起来是这样。因为当我在分析器之外运行程序时，GC 的发生似乎和所有这些优化之前一样频繁！我做了一些琐碎的检查（它是同一个程序，编译选项是一样的，机器/用途是一样的，输入都是一样的），我想知道探查器是如何运行的我没有被告知。自然，分析器必须在程序中的某个地方放置挂钩，以查看显示的所有信息。但是，如果没有这些钩子，您肯定会认为事情会运行得更顺利，而不是更少？

有人见过这样的事情吗？

编辑

我意识到当问题似乎不具体时，很难得到答案。只是想知道是否有足够的眼球会导致出现有用的提示。

【问题讨论】：

你如何“改善（我的）程序的垃圾生成特性”？
好吧，我从 SciTech 网站上提供的视频教程中吸取了一些教训。基本上使用程序中提供的各种计数器进行侦探工作。还有一些关于可能导致内存问题的提示，我解决了我能找到的那些。
但是有问题吗？您的应用是否遭受过多的 GC？
频率是基于时间的。内存分析器会大大降低程序的速度。
在没有附加调试器的情况下运行的发行版 GC 非常非常擅长它的功能。我有一个应用程序，我在其中做了大量工作来减少分配量（从 2.5 GiB 减少到仅 100 MiB - 它使用了一些非常低效的第 3 方解析库）。在调试模式和调试器中，更改非常显着。在没有调试器的发布模式下，几乎没有任何真正的区别。在我的实践中，我认为只有在内存中固定/固定指针时才应该真正关心 GC。如果没有 - 让 GC 完成它的工作，它会非常出色。

标签： .net garbage-collection profiling

【解决方案1】：

如果您的生产版本在内存较少的计算机上运行，您将更频繁地达到垃圾收集阈值，从而强制执行更多 GC。

.NET 程序往往会在您提供的内存越多时在内存中蔓延，并且通常开发机器拥有很多比最终用户最终运行您的程序的机器更好的资源（即非常好和可以理解，但你需要牢记这一点）。

【讨论】：

啊，我应该补充一点，代码是在同一台机器上分析的，与产品相同的用户。
垃圾回收与安装的 RAM 数量没有任何关系。
否，但垃圾回收率确实如此。除非您达到开始收集垃圾的阈值，否则运行时将让“死”对象堆积起来。
@Blindy 虽然这是真的，但您不应该忘记在 GC 运行之前内存分配存在限制（在运行时统计确定）。默认值是单个 MiB 的数量级，因此它们实际上与可用的总 RAM 没有任何关系 - 只有当您实际上一次需要那么多 RAM 时才会成为问题。如果您继续分配和取消分配，则对可用 RAM 几乎没有任何依赖。