最近看了
乙個同事
寫的模組，他為了提高程式執行的效率，對記憶體的使用做了很大的優化。
通常的做法是，根據自己的需求預先分配了乙個大的記憶體塊，然後分割開來，用鍊錶或者陣列管理起來，需要的時候只需要取出來用就可以，不用的時候就放回去。可以很大程度的減少從glibc分配和釋放記憶體的操作，大大加快了處理時間。
但是真心不建議這樣做，這種做法雖然提高了程式的效率，但是也限制了以後程式可修改的靈活性。提高了**的複雜度，要花更多的時間和精力去除錯。即使是復用以前成熟的記憶體池，也會讓**更難被他人讀懂。
如果作業系統的記憶體分配方式確實不能滿足你的效能要求，不做優化的程式效率得不到滿足。我的建議是，如果程式不是很特別的應用
hoard
和tcmalloc
這些第三方記憶體管理庫就很好了，只要在鏈結時稍微費點心思就能解決記憶體效能的問題。
如果你膝蓋中了一箭後，程式的可靠性或者應用場景有特殊的要求，非得用自己的**進行記憶體管理，也可以自己寫記憶體池，但這這個記憶體池一定要對其它透明，也就是說使用記憶體管理的函式不需要知道你記憶體管理的細節，管你是用雜湊表、鍊錶還是神馬堆，它只要malloc和free就可以了。再考慮到記憶體管理的瓶頸可能不是在乙個模組上，這種做法對整體的記憶體優化也是很方便的。
c 14對記憶體分配效能的重大優化
1.本質需求2.存在的問題3.解決方案簡述,c 14標準對記憶體優化的描述修改,會讓編譯器引入類似tcmalloc的記憶體分配優化策略,而不拘泥於原來的有乙個new語句,就分配一次記憶體的傻傻的情況.因此有理由相信用c 14的編譯器編譯出來的c 程式在記憶體分配上效能會有較多提公升.下面的文字 於c...
在Qt程式中對記憶體管理的建議
在qt程式中對記憶體管理的建議 1.使用new建立視窗或者物件的時候，除非有具體需要，一般建議建立父子關係或者從屬關係。因為這樣，當父視窗或者主物件被釋放掉時，其子視窗或者主物件也會一起被釋放。從而可以起到自動釋放資源的效果。例如 qdialog dialog new qdialog this 把父...
在不同模組分配和釋放記憶體時出錯的原因
問題 如果程式的模組中有乙個鏈結到靜態c c 執行期庫，那麼在這個模組中分配記憶體而在另乙個模組中釋放這塊記憶體將失敗。原因 造成失敗的原因是分配和釋放記憶體不是由相同的堆管理程式完成的，例如動態鏈結庫中的堆在預設情況下是由msvcrt.dll中的堆管理程式管理的 以動態鏈結的方式 而exe程式的堆...