ホームページ >バックエンド開発 >C#.Net チュートリアル >C# パフォーマンスの最適化
パフォーマンスはソフトウェア製品の品質を検討するための重要な指標であり、製品の機能と同様に重要です。ユーザーがソフトウェア製品を選択するとき、基本的には同様の製品のパフォーマンスを実際にテストして比較します。購入するソフトウェアを選択する際の重要な要素の 1 つとして。
ソフトウェアのパフォーマンスとは何ですか
1. メモリ消費量をダウングレードする
今日のコンピューターは一般に比較的大きなメモリを備えているため、多くの場合、パフォーマンスを最適化する手段は時間ではなくスペースです。 。ただし、これはメモリを不謹慎に浪費してもよいという意味ではありません。大量のデータを含むユースケースをサポートする必要がある場合、メモリが使い果たされると、オペレーティング システムは内部メモリと外部メモリを頻繁に交換します。その結果、実行速度が大幅に低下します
2. 実行速度
読み込み速度が向上します。
特定の操作の応答速度。クリック、キーボード入力、スクロール、並べ替え、フィルタリングなどが含まれます。
パフォーマンス最適化の原則
要件の理解
MultiRow 製品を例に挙げます。MultiRow のパフォーマンス要件の 1 つは、「数百万行のデータ バインディングの下でのスムーズなスクロール」です。 MultiRow プロジェクト全体の開発プロセス。
ボトルネックを理解する
経験によれば、パフォーマンス消費の 99% は 1% のコードによって引き起こされます。したがって、ほとんどのパフォーマンスの最適化は、この 1% のボトルネック コードを対象としています。具体的な実装は 2 つのステップに分かれています。まずボトルネックを特定し、次にボトルネックを解消します。
やりすぎないでください
まず第一に、パフォーマンスの最適化自体にはコストがかかることを認識する必要があります。このコストは、パフォーマンスの最適化に費やされる作業量に反映されるだけではありません。また、パフォーマンスの最適化、追加のメンテナンスコスト、新しいバグの導入、追加のメモリオーバーヘッドなどのために書かれた複雑なコードも含まれます。 よくある問題は、ソフトウェア開発が初めての一部の学生が、パフォーマンス最適化テクニックやデザイン パターンを不必要な箇所に機械的に適用し、不必要な複雑さをもたらしてしまうということです。パフォーマンスの最適化には、多くの場合、利点とコストの間のトレードオフが必要になります。
パフォーマンスのボトルネックを見つける方法
前のセクションで説明したように、パフォーマンスの最適化の最初のステップはパフォーマンスのボトルネックを見つけることです。このセクションでは主にパフォーマンスのボトルネックを見つけるためのいくつかのプラクティスを紹介します。
1. メモリ消費量を取得する方法
以下のコードは、特定の操作のメモリ消費量を取得できます。
// 在这里写一些可能消耗内存的代码,例如,如果想了解创建一个GcMultiRow软件需要多少内存可以执行以下代码 long start = GC.GetTotalMemory(true); var gcMulitRow1 = new GcMultiRow(); GC.Collect(); // 确保所有内存都被GC回收 GC.WaitForFullGCComplete(); long end = GC.GetTotalMemory(true); long useMemory = end - start;
2. 消費時間を取得する方法
以下のコードは、特定の操作の消費時間を取得できます。
System.Diagnostics.Stopwatch watch = new System.Diagnostics.Stopwatch(); watch.Start(); for (int i = 0; i < 1000; i++) { gcMultiRow1.Sort(); } watch.Stop(); var useTime = (double)watch.ElapsedMilliseconds / 1000;
ここでは、演算ループを 1000 回実行し、最後に消費時間を 1000 で割って最終的な消費時間を求めます。結果はより正確かつ安定し、予期しないデータを排除できます。
3. CodeReview を通じてパフォーマンスの問題を発見します。
多くの場合、パフォーマンスの問題は CodeReview を通じて発見できます。大量のデータを含むループには特別な注意を払う必要があります。ループ内のロジックはできるだけ早く実行する必要があります。 4.ANTS パフォーマンス プロファイラー
ANTS プロファイラーは、強力なパフォーマンス テスト ソフトウェアです。これは、パフォーマンスのボトルネックを見つけるのに非常に役立ちます。このソフトウェアを使用してパフォーマンスのボトルネックを特定すると、半分の労力で 2 倍の結果を達成できます。このツールをうまく使用すると、パフォーマンス上の問題があるコードを迅速かつ正確に特定できます。 このツールは強力ですが、完璧ではありません。まず第一に、これは有料ソフトウェアであり、部門が持っているライセンス番号はわずかです。次に、このソフトウェアの動作原理は、時間を記録するために IL にいくつかのフックを追加することです。そのため、解析中はソフトウェアの実行速度が実際の動作よりも遅くなり、取得されるデータは100%正確ではありませんが、ソフトウェアで解析されたデータは、問題を迅速に特定するための参考として使用する必要があります。これに完全に依存せず、他の手法と組み合わせてプログラムのパフォーマンスを分析しないでください。
パフォーマンスを最適化するための方法とテクニック
パフォーマンスの問題を特定した後、多くの解決策があります。この章では、パフォーマンス最適化の手法と実践方法をいくつか紹介します。
1. プログラム構造を最適化する
プログラム構造については、設計時に検討し、パフォーマンス要件を満たせるかどうかを評価する必要があります。後でパフォーマンスの問題が発見された場合は、構造の調整を検討する必要があり、これにより多くのオーバーヘッドが発生します。例:
1.1 GcMultiRowGcMultiRow は 100 万行のデータをサポートする必要があり、各行に 10 列があるとすると、1,000 万個のセルが必要となり、各セルには多くの属性が含まれます。最適化が行われていない場合、データ量が大きい場合、GcMultiRow ソフトウェアのメモリ オーバーヘッドが非常に大きくなります。 GcMultiRow が採用したソリューションは、ハッシュ テーブルを使用して行データを格納することです。ユーザーによって変更された行のみがハッシュ テーブルに配置され、変更されていない行のほとんどはテンプレートによって直接置き換えられます。これにより、メモリを節約するという目的が達成されます。
1.2 Spread for WPF/Silverlight (SSL)WPF的画法和Winform不同,是通过组合View元素的方法实现的。SSL同样支持百万级的数据量,但是又不能给每个单元格都分配一个View。所以SSL使用了VirtualizePanel来实现画法。思路是每一个View是一个Cell的展示模块。可以和Cell的数据模块分离。这样。只需要为显示出来的Cell创建View。当发生滚动时会有一部分Cell滚出屏幕,有一部分Cell滚入屏幕。这时,让滚出屏幕的Cell和View分离。然后再复用这部分View给新进入屏幕的Cell。如此循环。这样只需要几百个View就可以支持很多的Cell。
2. 缓存
缓存(Cache)是性能优化中最常用的优化手段.适用的情况是频繁的获取一些数据,而每次获取这些数据需要的时间比较长。这时,第一次获取的时候会用正常的方法,并且在获取之后把数据缓存下来。之后就使用缓存的数据。 如果使用了缓存的优化方法,需要特别注意缓存数据的同步,就是说,如果真实的数据发生了变化,应该及时的清除缓存数据,确保不会因为缓存而使用了错误的数据。 举例:
2.1 使用缓存的情况比较多。最简单的情况就是缓存到一个Field或临时变量里。
for(int i = 0; i < gcMultiRow.RowCount; i++) { // Do something; }
以上代码一般情况下是没有问题的,但是,如果GcMultiRow的行数比较大。而RowCount属性的取值又比较慢的时候就需要使用缓存来做性能优化。
int rowCount = gcMultiRow.RowCount; for (int i = 0; i < rowCount; i++) { // Do something; }
2.2 使用对象池也是一个常见的缓存方案,比使用Field或临时变量稍微复杂一点。 例如,在MultiRow中,画边线,画背景,需要用到大量的Brush和Pen。这些GDI对象每次用之前要创建,用完后要销毁。创建和销毁的过程是比较慢的。GcMultiRow使用的方案是创建一个GDIPool。本质上是一些Dictionary,使用颜色做Key。所以只有第一次取的时候需要创建,以后就直接使用以前创建好的。以下是GDIPool的代码:
public static class GDIPool { Dictionary<Color, Brush > _cacheBrush = new Dictionary<Color, Brush>(); Dictionary<Color, Pen> _cachePen = new Dictionary<Color, Pen>(); public static Pen GetPen(Color color) { Pen pen; if_cachePen.TryGetValue(color, out pen)) { return pen; } pen = new Pen(color); _cachePen.Add(color, pen); return pen; } }
2.3 懒构造
有时候,有的对象创建需要花费较长时间。而这个对象可能并不是所有的场景下都需要使用。这时,使用赖构造的方法可以有效提高性能。 举例:对象A需要内部创建对象B。对象B的构造时间比较长。 一般做法:
public class A { public B _b = new B(); }
一般做法下由于构造对象A的同时要构造对象B导致了A的构造速度也变慢了。优化做法:
public class A { private B _b; public B BProperty { get { if(_b == null) { _b = new B(); } return _b; } } }
优化后,构造A的时候就不需要创建B对象,只有需要使用的时候才需要构造B对象。
2.4 优化算法 优化算法可以有效的提高特定操作的性能,使用一种算法时应该了解算法的适用情况,最好情况和最坏情况。 以GcMultiRow为例,最初MultiRow的排序算法使用了经典的快速排序算法。这看起来是没有问题的,但是,对于表格软件,用户经常的操作是对有序表进行排序,如顺序和倒序之间切换。而经典的快速排序算法的最差情况就是基本有序的情况。所以经典快速排序算法不适合MultiRow。最后通过改的排序算法解决了这个问题。改进的快速排序算法使用了3个中点来代替经典快排的一个中点的算法。每次交换都是从3个中点中选择一个。这样,乱序和基本有序的情况都不是这个算法的最坏情况,从而优化了性能。
2.5 了解Framework提供的数据结构 我们现在工作的.net framework平台,有很多现成的数据数据结构。我们应该了解这些数据结构,提升我们程序的性能:
举例:
2.5.1 string 的加运算符 VS StringBuilder: 字符串的操作是我们经常遇到的基本操作之一。 我们经常会写这样的代码 string str = str1 + str2。当操作的字符串很少的时候,这样的操作没有问题。但是如果大量操作的时候(例如文本文件的Save/Load, Asp.net的Render),这样做就会带来严重的性能问题。这时,我们就应该用StringBuilder来代替string的加操作。
2.5.2 Dictionary VS List Dictionary和List是最常用的两种集合类。选择正确的集合类可以很大的提升程序的性能。为了做出正确的选择,我们应该对Dictionary和List的各种操作的性能比较了解。2.5.3TryGetValue 对于Dictionary的取值,比较直接的方法是如下代码:
if(_dic.ContainKey("Key") { return _dic\["Key"\]; }
当需要大量取值的时候,这样的取法会带来性能问题。优化方法如下:
object value; if(_dic.TryGetValue("Key", out value)) { return value; }
使用TryGetValue可以比先Contain再取值提高一倍的性能。
2.5.4 为Dictionary选择合适的Key。 Dictionary的取值性能很大情况下取决于做Key的对象的Equals和GetHashCode两个方法的性能。如果可以的话使用Int做Key性能最好。如果是一个自定义的Class做Key的话,最好保证以下两点:1. 不同对象的GetHashCode重复率低。2. GetHashCode和Equals方法立即简单,效率高。
2.5.5 List的Sort和BinarySearch性能很好,如果能满足功能需求的话推荐直接使用,而不是自己重写。
List<int> list = new List<int>{3, 10, 15}; list.BinarySearch(10); // 对于存在的值,结果是1 list.BinarySearch(8); // 对于不存在的值,会使用负数表示位置,如查找8时,结果是-2, 查找0结果是-1,查找100结果是-4.
复制代码
2.6 通过异步提升响应时间
2.6.1 多线程
有些操作确实需要花费比较长的时间,如果用户的操作在这段时间卡死会带来很差的用户体验。有时候,使用多线程技术可以解决这个问题 举例: CalculatorEngine在构造的时候要初始化所有的Function。由于Function比较多,初始化时间会比较长。这是就用到了多线程技术,在工作线程中做Function的初始化工作,就不影响主线程快速响应用户的其他操作了。代码如下:
public CalcParser() { if (_functions == null) { lock (_obtainFunctionLocker) { if (_functions == null) { System.Threading.ThreadPool.QueueUserWorkItem((s) => { if (_functions == null) { lock (_obtainFunctionLocker) { if (_functions == null) { _functions = EnsureFunctions(); } } } }); } } } }
这里比较慢的操作就是EnsureFunctions函数,是在另一个线程里执行的,不会影响主线程的响应。当然,使用多线程是一个比较有难度的方案,需要充分考虑跨线程访问和死锁的问题。
2.6.2 加延迟时间
在GcMultiRow实现AutoFilter功能的时候使用了一个类似于延迟执行的方案来提升响应速度。AutoFilter的功能是用户在输入的过程中根据用户的输入更新筛选的结果。数据量大的时候一次筛选需要较长时间,会影响用户的连续输入。使用多线可能是个好的方案,但是使用多线程会增加程序的复杂度。MultiRow的解决方案是当接收到用户的键盘输入消息的时候,并不立即出发Filter,而是等待0.3秒。如果用户在连续输入,会在这0.3秒内再次收到键盘消息,就再等0.3秒。直到连续0.3秒内没有新的键盘消息时再触发Filter。保证了快速响应用户输入的目的。
2.6.3 Application.Idle事件
在GcMultiRow的Designer里,经常要根据当前的状态刷新ToolBar上按钮的Disable/Enable状态。一次刷新需要较长的时间。如果用户连续输入会有卡顿的感觉,影响用户体验。GcMultiRow的优化方案是挂系统的Application.Idle事件。当系统空闲的时候,系统会触发这个事件。接到这个事件表示此时用户已经完成了连续的输入,这时就可以从容的刷新按钮的状态了。
2.6.4 Invalidate, BeginInvoke. PostEvent 平台本身也提供了一些异步方案。
例如;在Winform下,触发一块区域重画的时候,一般不适用Refresh而是Invalidate,这样会触发异步的刷新。在触发之前可以多次Invalidate。BeginInvoke,PostMessage也都可以触发异步的行为。
2.7 了解平台特性
如WPF的DP DP相对于CLR property来说是很慢的,包括Get和Set都很慢,这和一般质感上Get比较快Set比较慢不一样。如果一个DP需要被多次读取的话建议是CLR property做Cache。
2.8 进度条,提升用户体验
有时候,以上提到的方案都没有办法快速响应用户操作,进度条,一直转圈圈的图片,提示性文字如"你的操作可能需要较长时间请耐心等待"。都可以提升用户体验。可以作为最后方案来考虑。
目前已有很多使用C#编写的开发工具,其中值得一提的是ComponentOne Studio Enterprise,这是一款专注于企业应用的.NET全功能控件套包,支持WinForms、WPF、UWP、ASP.NET MVC等多个平台,帮助在缩减成本的同时,提前交付丰富的桌面、Web和移动企业应用。