.NET Framework 使用类别中的性能规则标识可以优化的特定方法,还标识可以就性能问题进行调查的更常规的使用模式,如垃圾回收和锁争用。
对 String.Concat(String, String) 的调用在分析数据中占很大比例。 请考虑使用 StringBuilder 类根据多个段构造字符串。 |
|
在第 2 代垃圾回收中正在回收相对大量的 .NET 内存对象。 如果在第 1 代回收后仍然存在太多生存期较短的对象,则内存管理的成本可能很容易会变得过高。 |
|
对 Equals 方法或公共值类型的相等运算符的调用在分析数据中占很大比例。 请考虑实施更有效的方法。 |
|
分析数据中 .NET Framework 异常处理程序的调用率高。 请考虑使用其他控制流逻辑来减少引发的异常数。 |
|
对该类型的 GetHashCode 方法的调用在分析数据中占很大比例或 GetHashCode 方法分配内存。 降低此方法的复杂性。 |
|
该类型的 CompareTo 方法开销巨大或此方法分配内存。 降低 CompareTo 方法的复杂性。 |
|
对 System.Reflection 方法(如 InvokeMember 和 GetMember)或 Type 方法(如 InvokeMember)的调用在分析数据中占很大比例。 如果可能,请考虑用对依赖程序集的方法的早期绑定替代这些方法。 |
|
对 String.Split 或 Substring 方法的调用在分析数据中占很大比例。 如果要测试字符串中是否存在子字符串,请考虑使用 IndexOf 或 IndexOfAny。 |
|
分析运行期间收集的系统数据指示 .NET Framework 内存堆已接近托管堆在 32 位进程中可以达到的最大大小。 请考虑使用 .NET 内存分析方法重新进行分析,并优化应用程序对托管资源的使用。 |
|
在第 1 代垃圾回收中正在回收相对大量的 .NET 内存对象。 如果在第 0 代回收后仍然存在太多生存期较短的对象,则内存管理的成本可能很容易会变得过高。 |
|
在第 2 代垃圾回收中正在回收大量 .NET 内存对象。 如果在第 1 代回收后仍然存在太多生存期较短的对象,则内存管理的成本可能很容易会变得过高。 当锁争用的发生率超过规则 DA0005 的上限阈值时,将激发此规则。 |
|
分析期间收集的系统性能数据表明,与应用程序总处理时间相比,垃圾回收所用时间很长。 |
|
分析期间收集的系统性能数据表明,与应用程序总处理时间相比,垃圾回收所用时间过长。 当垃圾回收所用时间超过规则 DA0023 的上限阈值时,将激发此规则。 |
|
随分析数据一起收集的系统性能数据表明应用程序执行期间锁争用的发生率很高。 请考虑使用并发分析方法重新进行分析,以找出争用的原因。 |
|
随分析数据一起收集的系统性能数据表明,应用程序执行期间锁争用的发生率过高。 请考虑使用并发分析方法重新进行分析,以找出争用的原因。 当锁争用的发生率超过规则 DA0038 的上限阈值时,将激发此规则。 |