.NET Framework 使用效能規則
.NET Framework 使用分類中的效能規則會識別可最佳化的特定方法,也會識別其他可針對效能問題調查的一般使用模式,例如記憶體回收和鎖定爭用。
String.Concat(String, String) 的呼叫在程式碼剖析資料中佔有很高的比例。請考慮使用 StringBuilder 類別從多個區段建構字串。 |
|
相當大量的 .NET 記憶體物件正在層代 2 記憶體回收中回收。如果太多存留短暫的物件在層代 1 記憶體回收中未被回收,記憶體管理成本可能很容易變得過高。 |
|
對 Equals 方法或公用實值型別之等號比較運算子的呼叫佔程式碼剖析資料顯著的比例。請考慮實作更有效率的方法。 |
|
程式碼剖析資料中呼叫了高比率的 .NET Framework 例外狀況處理常式。請考慮使用其他控制流程邏輯,以減少擲回的例外狀況數目。 |
|
此型別之 GetHashCode 方法的呼叫在程式碼剖析資料中佔有很高的比例,或者 GetHashCode 方法配置了記憶體。請降低方法的複雜度。 |
|
此型別的 CompareTo 方法高度耗費資源,或者此方法配置了記憶體。請降低 CompareTo 方法的複雜度。 |
|
System.Reflection 方法 (例如 InvokeMember 和 GetMember) 或 Type 方法 (例如 InvokeMember) 的呼叫在程式碼剖析資料中佔有很高的比例。 請盡可能考慮用相依組件之方法的早期繫結來取代這些方法。 |
|
String.Split 或 Substring 方法的呼叫在程式碼剖析資料中佔有很高的比例。 如果您要測試字串中是否存在子字串,請考慮使用 IndexOf 或 IndexOfAny。 |
|
在執行程式碼剖析期間所收集的系統資料指出,.NET Framework 記憶體堆積接近 32 位元處理序內允許的 Managed 堆積大小上限。請考慮使用 .NET 記憶體程式碼剖析方法重新進行程式碼剖析,並且最佳化應用程式對 Managed 資源的使用。 |
|
相當大量的 .NET 記憶體物件正在層代 1 記憶體回收中回收。如果太多存留短暫的物件在層代 0 記憶體回收中未被回收,記憶體管理成本可能很容易變得過高。 |
|
大量 .NET 記憶體物件正在層代 2 記憶體回收中回收。如果太多存留短暫的物件在層代 1 記憶體回收中未被回收,記憶體管理成本可能很容易變得過高。當爭用鎖定的比率超過規則 DA0005 的臨界值上限時,就會引發此規則。 |
|
程式碼剖析期間收集的系統效能資料指出,相較於應用程式處理總時間,記憶體回收所花費的時間量相當高。 |
|
程式碼剖析期間收集的系統效能資料指出,相較於應用程式處理總時間,記憶體回收所花費的時間量過高。當記憶體回收所花費的時間量超過規則 DA0023 的臨界值上限時,就會引發此規則。 |
|
隨程式碼剖析資料一起收集的系統效能資料指出,在應用程式執行期間發生相當高比率的鎖定爭用。請考慮使用並行程式碼剖析方法重新進行程式碼剖析,找出爭用原因。 |
|
隨程式碼剖析資料一起收集的系統效能資料指出,在應用程式執行期間發生比率過高的鎖定爭用。請考慮使用並行程式碼剖析方法重新進行程式碼剖析,找出爭用原因。當爭用鎖定的比率超過規則 DA0038 的臨界值上限時,就會引發此規則。 |