快手KCode比賽心得

題目與參賽代碼：https://github.com/AllenDuke/kcode

 

這應該是我第一次參加計算機類比賽，除開學校舉辦的程序設計賽的話。我能感受到本身的水平提高了不少，學到了解決問題可從多個角度入手，嘗試，用多個指標來衡量，而後挑出最優角度，最後從這個角度再出發，不斷優化。

通常個人思路以下：

先用單線程讀取與處理，若是能夠先作流式計算，不過最後仍是要和一次性讀入進行比較。

再考慮更換好的數據結構和算法，接着更換爲多線程並行計算。

利用特徵，減小沒必要要運算，如不判斷是否爲空，特別是要注意重寫equal和hashCode方法，優化必要運算，如利用位運算，或者在某些特定場景下用加法代替乘法。

重用對象，減小對象的產生，減輕gc，爲此我本身設計了一個可重用的SDS來代替字符串拼接和StringBuilder，但彷佛拼接的量少時，如3個，拼接的速度更快。

在內存足夠時，增長冗餘來減小鏈接，增長索引來減小無效遍歷。

 

應該是止步複賽了，但我既不服氣又服氣。複賽線上用的應該是機械硬盤，多線程處理沒有幫助，反而會加劇IO負擔，那麼你們都只能單線程處理了（但我認爲本身在多線程上有優點的），估計一階段你們都應該是差很少的，那麼都在拼二階段了。在優化二階段的過程當中，我想到了在一階段中提早查詢來預熱數據，那麼二階段就能夠直接獲取了，接着優化，我還想到了在(StringA,StringB)->StringC時，轉換爲Long->StringC，Long的高32位保存StringA的hashCode，低32位保存StringB的hashCode，減小String.hashCode運算，固然這是有hash衝突的風險的。最後我還想到了定製一個IntHashMap和LongHashMap用於肯定key位int爲long的狀況，以減小Integer和Long的產生，減小equal的無用判斷。至此我認爲本身已經優化到極限了，然而仍是比不上大佬們。

我不服氣的是，我自認爲的極限卻仍是看不到大佬們的身影，我不服氣的是大佬們輕易想到用數組（我用的是Map，尚未測試速度差了多少）和神奇的hash函數（我有嘗試過更換好的hash函數，但總會衝突），我不服氣的是，最後竟要輸在納秒級別的差別上。

我服氣的是，大佬之因此是大佬，是由於大佬在什麼時間，什麼地點都是大佬。

不過我仍是挺滿意的，由於在我本身看來，我有了很大的突破，而這種突破不會中止。在大佬們的討論和開源的代碼中，我學習到了不少，除了上述所說的神奇的hash函數外，還有JNI和各類優化手段，是很感激的！

 

不以物喜，不以己悲，繼續學習。