我正在分析在生产中表现不佳的应用程序（使用VS 2010）。 VS 2010提出的建议之一是：
第1代垃圾收集的比率相对较高。如果，通过 设计中，大多数程序的数据结构都是分配的 坚持了很长时间，这通常不是问题。然而， 如果此行为是无意的，您的应用可能会固定对象。如果 你不确定，你可以收集.NET内存分配数据和 对象生命周期信息，以了解内存的模式 分配您的应用程序使用。
在Google上搜索会显示以下链接=＆gt; http://msdn.microsoft.com/en-us/library/ee815714.aspx。我是否可以做一些明显的事情来减少这个问题？我似乎迷失在这里。
双击“错误列表”窗口中的消息以导航到 标记分析数据的视图。找到Gen 0的.NET CLR Memory＃ 收集和.NET CLR内存＃Gen 1集合列。 确定程序执行的具体阶段是否存在 垃圾收集更频繁发生。比较这些值 到GC列中的％Time，看是否有托管内存的模式 分配导致过多的内存管理开销。
要了解应用程序的托管内存使用模式， 配置文件再次运行.NET内存分配配置文件和请求 对象生命周期测量。
有关如何提高垃圾收集性能的信息， 请参阅Microsoft上的垃圾收集器基础知识和性能提示 网站。有关自动垃圾开销的信息 集合，请参见大对象堆未覆盖。
答案 0 :(得分：1)
相关的一行是：
要了解应用程序的托管内存使用模式，请再次运行.NET内存分配配置文件并请求对象生命周期测量。
您需要了解应用程序分配了多少对象，以及它们活动的时间和持续时间。您可能在某个循环内部分配了数百（或数千！）个微小对象，而没有真正考虑当引用超出范围时回收该内存的后果。
http://msdn.microsoft.com/en-us/library/ms973837.aspx州：
现在我们已经有了一个基本模型来说明事情是如何运作的那样 考虑一些可能会导致速度变慢的问题。那 会让我们知道我们应该尽量避免哪些事情 从收藏家那里获得最佳表现。
分配太多
这确实是最基本的问题。分配新的 垃圾收集器的内存真的非常快。如你看到的 在上面的图2中，所有需要发生的事情通常都是为了 要移动的分配指针，以便为新对象创建空间 “分配”方面 - 它没有比这快得多。然而， 垃圾收集迟早会发生，一切都在发生 相等，这比晚更快发生更好。所以你要 确保在创建新对象时确实如此 这样做是必要和适当的，即使只创造一个也是如此 快。
这可能听起来像是明显的建议，但实际上它非常容易 忘记你写的一小段代码可能会引发很多 分配。例如，假设您正在编写比较 某种功能，并假设您的对象有关键字 字段，并希望您的比较不区分大小写 给定顺序中的关键字。现在在这种情况下你不能只是比较 整个关键字字符串，因为第一个关键字可能非常 短。使用String.Split来破解关键字是很诱人的 把它串成碎片，然后按顺序比较每一块 正常的不区分大小写的比较。听起来不错吧？
好吧，事实证明这样做并不是一个好主意。您 看，String.Split将创建一个字符串数组，这意味着 最初在关键字中的每个关键字的一个新字符串对象 字符串再加上一个数组对象。哎呀！如果我们这样做 在某种情况下，这是很多比较和你的 现在两行比较功能创造了非常多的功能 临时对象。突然间垃圾收集器将会是 代表你努力工作，甚至是最聪明的人 收集计划只有很多垃圾清理。更好 编写一个不需要分配的比较函数 所有