数独_性能分析
目錄
性能分析
初步分析
VS性能分析
問題收獲：
性能分析
在實現了數獨項目基本功能的基礎上，我們使用Visual Studio集成的性能探查器對項目的性能進行分析，從各方方面包括文件的讀寫問題、字符串的處理上進行改進。
初步分析
在編碼階段，查閱相關資料時，了解到文件讀寫會是一個占用時間比較長的問題。于是在編碼時就考慮到這個問題。首先我分4個方面去進行測試：
-
逐字符寫入文件
-
逐數獨寫入文件
-
以30個數獨為單位寫入文件
-
全部數獨一次性寫入文件
| 1000（個） | 203ms | 100ms | 16ms | 16ms |
| 10000（個） | 1859ms | 956ms | 262ms | 234ms |
| 1000000（個） | ? | ? | 13000ms | 13044ms |
分析上述時間發現一次性寫入1000000個數組時時間反而變長，于是猜想可能是過大的數組在初始化時耗時較長，于是測試memset時間，如下：
| char [10000] | 1ms |
| char [1000000] | 230ms |
分析時間后，發現按照最快速度，生成1000000個數獨，時間消耗還是很長，于是研究其他c++文件讀寫方式，發現并不能很好的提高速度。
VS性能分析
使用visual studio2017進行性能分析，由于項目需求里只對數獨生成功能有性能要求，于是關于項目的性能優化及分析主要針對數獨生成部分，即generate_final 函數。
第一次分析
在分析報告中發現，一個簡單的賦值語句竟然是耗時最多的部分。這句話是用來對由第一句經過全排列加平移構成的數獨進行交換行的操作。但是還是不清楚為什么耗時這么長，首先懷疑是swap_line[s][j] 嵌套的原因，于是修改后再進行性能分析。
?
第二次性能分析
將套拆分出來后，性能還是沒有改變，在意料之中。于是猜想是string類的原因，此處的all[][]二維數組是string 類型，可能會出現耗時過大的問題，于是將全部string類改為 char類型，并將string的函數手動用char類型實現。
?
第三次性能分析
再次進行性能分析，發現將全部string類改為 char類型后這里的時間耗費減小了很多，可以達到要求。
但是文件寫入便成為耗時最大的部分，占整個函數的72.68%
?
?
為了減少文件寫入次數，我嘗試采用不同個數的獨為單位進行讀寫，一下為測試3次取平均值，如圖：
| 60個 | 71.24% | 2043ms | <0.05% |
| 300個 | 69.43% | 2005ms | <0.05% |
可以發現，性能的優化不明顯，且隨著數組的增大程序執行所消耗的內存便會增大，所以仍然以60個數獨作為單位進行寫入文件。
我再次嘗試使用其他文件讀寫方式進行測試，使用fputs進行文件寫入
| 60個 | 69.89% | 2104ms | <0.05% |
性能效果和使用ofstream差異不明顯。
最終性能分析圖
最終程序里花費時間最多的是文件的讀寫，其次是字符的賦值操作。
問題收獲：
開始在使用visual studio做性能分析時，遇到了問題。于是我先進行了不同輸入方式程序運行的時間，沒有進行性能分析測試，所以在之前的比較中可能會有細微的差異。在做性能分析后，發現花費最多的竟然是string字符串的處理，所以在之后的項目實踐中，在寫好最初版本后，先進行性能分析，然后有針對性的進行優化，而不是憑經驗優化。
其他博客：
? ? ? ? 軟件工程個人項目— 數獨
? ? ? ??設計實現過程（另一篇博客）
? ? ? ??單元測試（另一篇博客）
總結
- 上一篇： 谷歌Android各版本的代号变迁
- 下一篇： Map.Entry