最近寫了個小程式，合併兩本英語詞典的例句。演算法很簡單，就是用個鍵值對的資料結構來儲存詞條，詞作為鍵，例句作為值，如果鍵已存在，就將例句加在已有例句的末尾。最後輸出全部鍵值對到文字檔案。因為還要用mdxbuilder將文字檔案轉成mdict格式的詞典，轉換過程中是會重新排序的，所以輸出到文字檔案時，不必考慮排序，比如-able可以出現在最前面，也可以出現在abide後面，無關緊要。
用什麼資料結構呢？可供選擇的主要有dictionary，sortedlist，sorteddictionary。當然還有其他一些類似的類可用，但覺得我這個需求並不特殊，沒必要用第三方為了特殊目的開發的庫，所以就在.net framework提供的這三個類裡選擇了。hashtable太老，不支援泛型，用起來太麻煩，就不考慮了。至於dictionary的其他變體，如concurrentdictionary等，也不考慮。
說實話以前對它們的區別沒什麼研究，查了下，結論很簡單易懂，但必須通過實踐來檢驗。
測試結果，dictonary最快，134551毫秒，sortedlist其次，135995毫秒，sorteddictionary最慢，136070毫秒。（簡單地用stopwatch，不在意那麼精確）
這裡不想討論為什麼有這個差距，因為隨便查一下就能找到三個類的區別，不用我多費口舌。
總共處理了大約30萬詞條，耗時約2分鐘（2023年的老機器，耗時包括每隔200詞條顯示一次進度的開銷），相對這個耗時來說，不到2秒鐘的差距可以說沒什麼大礙。也就是說，只有處理相當大的資料，比如300萬，才可能在使用者體驗上有顯著的差異。
所以我想說的是，網上有不少比較不同類的效能差異的帖子。了解一點是好的，但是關鍵在於具體的應用。一般來說，只有相當大的資料規模時，這種效能差異才比較顯著。不太大的資料規模，差異不大，不必過於糾結用那個。所以平時不必過於熱衷這類帖子，也不必將掌握此類效能差異的知識當作所謂「基本功紮實」。只要意識到類似功能的類可能會有效能差異，具體選用哪個，碰到具體的需求時再查下資料也不遲。這不應作為優先考慮的學習目標。至於為了應付求職面試，那是另外一回事。但是我想多數單位，其實也不見得每天要處理海量資料，很多此類的面試問題其實沒什麼應用價值。
更重要的是演算法。比如上面這個例子，將每隔200詞條顯示一次進度改成每隔400顯示一次，即使用sorteddictionary也只要86982毫秒，足足快了近50秒。可見，在這個問題上，瓶頸在於ui，而將sorteddictionary換成dictionary，對效能並沒有決定性的影響。
所以在處理效能問題上，首先要考慮瓶頸在**，而瓶頸，一般不會在這種類和資料結構的差別上。
關於省市聯動的一點小心得
省市聯動，之前我的玩法是每乙個select變動，都發請求到後台進行處理，後台將json發回前台，前台進行後面兩層或者一層的資料填充，後來發現這樣玩效率實在太過低下，我寫的也不太好，會造成一些無用的請求 一開始本來還好啦，可是後來我們增加了乙個功能，根據使用者所存在系統裡得位址資訊來填充使用者資訊，世...
github的一點小心得
很多朋友在github上建立了 倉庫後，急急忙忙的就在本地按照網上的說法，如下 cd dir git init git remote add git add git commit 但是這樣可能就會出現各種蛋疼的問題。最後發現有個更簡單的方法。在github上建立好 倉庫及專案之後，配置好git，然後...
關於晶元選型的一點小小心得
隨著電子技術的不斷發展，各種功能的晶元層出不窮。積體電路的發展基本向著高整合 低功耗方向發展。這在給我們的研發工作帶來了極大方便的同時，也為我們在實際研發過程中的選型問題帶來了不便。我從事晶元推廣工作以來，經過與客戶的討論和自己的經驗，認為研發工作中晶元的選型應考慮以下問題 第一 效能。我們選好了i...