Note: SE Class's Individual Project

2019-11-17 02:52:34

字體：大中小

來源：轉載

供稿：網友

Note: SE Class's Individual PRoject

雖然第一個Project還有點小問題需要修改，但是大體已經差不多了，先把blog記在這里，算是開博第一篇吧！

1.項目預計的用時

本來看到這個題的時候想的并不多，但是看了老師的要求才覺得如此麻煩ORZ……尤其是動不動出現的o points更是嚇得我認認真真的把老師的要求讀了好幾遍，可憐我一個英語這么差的人真不容易……

項目要求要用C#或者C++，這兩個語言我都是略懂，但是有些用法還是不了解的，因此：

-計劃學習C#+百度一些用法的時間：2小時

-項目本身打算寫兩個類，一個是遍歷搜索文件夾的，另外一個用來統計單詞的。感謝上學期OO的吳際老師，我上學期java寫的遍歷文件夾的代碼還能拿來用，因此這部分計劃用時：2小時

-另外一個統計單詞的類就要相當于要重新寫了，不過考慮到也就是正則表達式然后再提取的問題，也沒做多想，計劃用時：4小時

2.項目實際用時

說起來這都是淚啊！！！真正寫起來我才發現老師的要求多么讓我想跪！我整個一天坐立不安，心緒不寧，一會兒實在寫不下去上床睡一會一睡就是2個多小時，一會兒在苦思冥想Extended Mode的算法一個人大晚上坐在綠園邊上啃著燒餅夾里脊！最最坑爹的一件事情是，到了晚上，我都已經寫完了，然后一個同學來問我問題，我才發現我看的是老師去年的要求！今年和去年的這部分完！全！不！一！樣！！天哪，想死的心都有了。所幸，我在讀了今年的要求以后，發現好像比去年的要簡單了（去年那段代碼我還沒刪呢都是淚啊！……

于是實際用時是：

-學習和C#和百度相關內容：估計花了預計的2小時吧……相關網頁一直都沒關，不過這個時間是離散的，基本都是有什么問題不會才百度然后查找解決方案。

-完成遍歷文件夾的類：2小時左右。本來覺得只是修改一下Java的代碼應該比較容易，因為以前也做過從C#移植到Java的工作，結果坑爹的是發現C#的File類完全沒有Java的好用，于是學習了一下C#這方面的操作方法（吐槽：Directory和File屬于兩類還真是好難用啊……

-完成統計單詞的類：12+小時…… 先不說在這部分坑了一下把題看錯了耽誤了多少時間，關于正則表達式的構建也夠麻煩……本來想的是很簡單的就像老師描述的那樣構建，后來發現123file這種情況表達式會把file當成一個單詞提取出來，問了老師老師說不行T T 為了不得o points還得苦思冥想解決辦法，來來回回試著改了好幾次正則表達式還是被MatchCollection這個非重疊匹配坑了，于是只好回歸最簡單的解決方法……如果小伙伴們有好的正則表達式麻煩告訴我下。

還有就是我用的是System.Linq進行的排序，這個默認的字典序排出來真的是字典的樣子，不是按照ASCII來的也是跪了= =問了老師也不知道行不行老師還沒回復……不行還得改……（關于字典序的問題，請大家直接跳到4.（4），做了點更新）

3.項目的表現和性能的分析

需要一提的是我在思考算法的時候就覺得哈希表很好用（對于頻繁查找單詞只有O（1）的復雜度確實很理想），于是就采用了Dictionary這個哈希表的結構，再加上排序什么的都用了Linq內置的方法，因此感覺性能上還可以。我曾經試圖讓其掃描VS2012的安裝文件夾（3G大），用時是1min25sec，統計的結果是1.06M，應該還可以提高的吧！只是我現在還沒有做什么性能優化的工作，如果以后做了再補上這里。（這段是最初寫的內容）

修改內容：

這是VS2012分析出來的掃描VS安裝文件夾（3G大）的結果，其實我也看不太懂還在研究中……

下面這張圖是相關函數的使用情況，但是不知道為什么函數名加載不出來……麻煩了解的同學能解答一下！

下圖是性能分析系統給出的警告，可見程序在垃圾回收這里有很多開銷：

我推測是因為我對Substring方法的過多使用，由于調整了算法，基本上每次循環都需要使用Substring。而Substring似乎每次會創建一個新對象的引用（有待查證），那這開銷是非常大的了。我用一個小樣例測試時系統也給出了這方面的警告：

關于Substring的優化還沒有做，等研究清楚了再補上。

補上優化結果：

按照我昨天的猜測，我今天對Substring這句進行了優化。其實之所以用這個方法是為了避免造成非重疊匹配，我想到很蠢的方法就是把已經匹配的串的第一個單詞前的內容全都刪掉，得到新的源串。后來我就想，怎么可能會沒有從規定下標開始匹配的方法呢？一查，果然有Regex.Match(string input, int startat)這個重載方法，于是果斷刪掉Substring，重新進行性能測試。以下是新的測試結果，還是對VS2012的安裝文件夾（3G大）的掃描：

從上圖可見，平均CPU使用率比原來降低了不少，最高都沒有突破60%（其實我懷疑這個是不是和機器當前的負載也有關？我今天測試前清理了一下內存）。

執行單個工作最多的函數占的比例也明顯下降了，見下圖：

最終警告也成功消除了，這個優化應該算是成功的！見下圖：

最后我對優化后統計這個3G文件夾的詞頻用時進行了統計：

-統計單個詞：用時15.97s，結果1.06M

-統計連續兩個詞：用時18.8s

-統計連續三個詞：用時19.16s

這真是比原來的1min25sec快多了啊~

4.項目的測試樣例

今天來補充一下測試樣例（只對一些結果進行了截圖）：

-（1）、測試大小寫合并能力

file123 file File 123file files

說明：本例主要測試能否在大小寫不敏感的情況下將相同的單詞合并并選取字典序在前的單詞。除此之外，123file不是一個單詞，其中的file由于并不是由空白符和非字母數字分隔的，也不能作為一個單詞，因此File出現的次數是2（這里改了好久我會說）。

期待&運行結果：<File>:2 <file123>:1 <files>:1 -（2）、測試詞的區分能力

abbsd-dnsd((@(@*# fahfh 123file*$(^( File

說明：本例主要測試能否根據分隔要求挑出正確的單詞

期待&運行結果：<File>:1 <abbsd>:1 <dnsd>:1 <fahfh>:1 -（3）、測試老師的博客

樣例太長了就不貼了，請大家直接進http://m.survivalescaperooms.com/jiel/p/3978727.html，就是直接把老師的博客內容copy了一下。老師的博客格式是比較規范的，沒有亂七八糟的符號，基本都是空格分隔，是一個很理想的測試樣例（誰說老師博客沒什么的！老師博客深藏功與名！我之前跑的結果都是錯的今天才發現了錯誤！！）也算是對實際問題的一個分析吧！對老師的博客分析結果如下：

a.單個詞詞頻分析（只貼2張圖）

運行結果：

b.連續的兩個詞

運行結果：

c.連續的三個詞

運行結果：

請注意：如果有哪位同學對老師博客內容的分析結果和我不一致的請快點告訴我>_<（我怕o points……

-（4）、測試詞的排序能力

File file “windows”, “windows95” and “windows7” ONE Word; Office” “Office15” “iPhone4” “Iphone5” “windows”windows32a“windows95”, “windows98” “windows2000”

說明：本例本來想測試程序對于字典序的排序情況，奈何Linq的字典序就是不按ASCII出牌！我和老師關于字典序的最新討論請大家閱讀http://m.survivalescaperooms.com/jiel/p/3978727.html的評論部分，其間我還參考了http://stackoverflow.com/questions/22700300/how-does-orderby-work-with-regard-to-strings-in-c這個問答以及MSDN上的解釋http://msdn.microsoft.com/en-us/library/system.stringcomparer.aspx，但是！最后我還是默認了Linq這種字典序的排法了！如果大家和我的順序是一樣的我就認同這種排法了！

最新更新：在老師的回復下，這個問題終于解決了！終于能按照ASCII順序排了~請大家結合Linq使用.OrderBy(o => o, StringComparer.Ordinal)即可（不是StringComparer.InvariantCulture哦，這個用了就是上面的結果）。其實也可以自己寫一個按照ASCII排序的接口^_^（你不就是懶不想寫嗎！

運行結果：

-（5）、測試包含中文的情況

Myapp.exe C:/Users/dell/Desktop/TestMyapp.exe -e2 C:/Users/dell/Desktop/TestMyapp.exe -e3 C:/Users/dell/Desktop/TestMyapp.exe -e4 C:/Users/dell/Desktop/TestMyapp.exe C:/Users/dell/Desktop/Test/MyappMyapp.exe C:/Users/dell/Desktop/Test/ReceiverMyapp.exe C:/Users/dell/Desktop/Test/測試空文件夾Myapp.exe C:/Users/dell/Desktop/Test/1_測試大小寫合并能力.txtMyapp.exe C:/Users/dell/Desktop/Test/2_測試詞的區分能力.txtMyapp.exe -e2 C:/Users/dell/Desktop/Test/2_測試詞的區分能力.txtMyapp.exe -e3 C:/Users/dell/Desktop/Test/2_測試詞的區分能力.txtMyapp.exe C:/Users/dell/Desktop/Test/3_老師的博客.txtMyapp.exe -e2 C:/Users/dell/Desktop/Test/3_老師的博客.txtMyapp.exe -e3 C:/Users/dell/Desktop/Test/3_老師的博客.txtMyapp.exe C:/Users/dell/Desktop/Test/4_測試詞的排序能力.txtMyapp.exe C:/Users/dell/Desktop/Test/5_測試包含中文的情況.txtMyapp.exe -e3 C:/Users/dell/Desktop/Test/6_測試連續三詞的情況.txtMyapp.exe -e2 C:/Users/dell/Desktop/Test/7_超級變態的連續兩詞情況.txtMyapp.exe -e3 "D:/Microsoft Visual Studio 11.0"

說明：我才不會說這是我準備的指令集！這條要多謝@徐大俠的提醒。按照老師的規定，中文應該也算是一個分隔符了，所以中文應該不影響測試結果才是正常。這個例子順便也測試了少于3個字母的比如e2、C是不能作為單詞的！

期待&運行結果：