因為Jeff Dean自己不寫這些核心程式碼，那麽世界上也許就沒有第二個人能寫出更好的答案了。
剛好自己最近就在寫谷歌Sanjay Ghemawat的 tcmalloc的對標程式碼，做自研C/C++記憶體分配庫，對標的是Google Tcmalloc庫(Google著名的大牛Sanjay Ghemawat開發，Jeff Dean的搭檔，The Google File System的第１作者，也是著名的MapReduce論文的第2作者)，寫得非常艱難。主要難在效能最佳化，谷歌這兩位大神的程式碼雖然是十多年前的作品，細讀下來，各種corner case的細節上，包括各種技巧的把握上，每一處細節都不浪費開銷，一個記憶體分配庫硬是幾萬行程式碼沒有什麽地方有硬傷，這就是頂級程式設計師最厲害的地方，這部份程式碼比那個時代同期的幾個記憶體分配庫效能高出幾倍，挺傳奇的。頂級程式設計師的功力，一般程式設計師給他再多時間再多人力，怕也是很難實作如此高效能的記憶體分配庫。
近十多年，IT行業的軟硬技術進步也是非常巨大的，所以考慮盡量用全部最新的軟硬件技術，也許能快一些。目前正在寫的自研記憶體分配庫，已經完成的程式碼已經比tcmalloc庫快了，重點是新增自動支持NUMA按cpu node分組分配記憶體(盡量分配近端記憶體，近端記憶體比遠端大約硬件上延遲時間低三倍)，自動支持hugepage2M/1G(自動將hugepage切成小片分配，存取速度更高)，支持C++11中預設16byte對齊，SSE指令更加完美的支持。其它目標是更穩定平滑的記憶體申請釋放時間開銷，更小的記憶體碎片，更小的記憶體浪費。
從今年三四月份開始做，中間有其它一些小產品開發，所有程式碼均從頭開始寫，主要思路是盡量多使用CPU硬件新特性，一點一點覆蓋掉tcmalloc庫的功能，最核心的程式碼已經寫完，還剩幾處corner case，小規模測試中，在啟用hugepage 2M的場景下大規模小字節塊有接近一倍的效能提升，其中大部份來自於hugepage 2M的帶來效能提升，所以電腦硬件本身的提升是根本，演算法艱難的改來改去只帶來了小部份的提升，測試16字節1000萬條記憶體申請後再依次釋放，平均每次申請13ns,每次釋放7ns,每次申請+釋放總體在20ns, 對比tcmalloc大約35ns。後續正式版弄完後，會放出一個二進制庫的評估測試版，以及寫一篇小文章簡單介紹一下主要最佳化。一句話總結就是軟件更好的支持硬件新特性，帶來了效能提升。
