在模块内对内存的分配过早优化的缺点

最近看了一个同事写的模块，他为了提高程序执行的效率，对内存的使用做了很大的优化。

通常的做法是，根据自己的需求预先分配了一个大的内存块，然后分割开来，用链表或者数组管理起来，需要的时候只需要取出来用就可以，不用的时候就放回去。可以很大程度的减少从glibc分配和释放内存的操作，大大加快了处理时间。

但是真心不建议这样做，这种做法虽然提高了程序的效率，但是也限制了以后程序可修改的灵活性。提高了代码的复杂度，要花更多的时间和精力去调试。即使是复用以前成熟的内存池，也会让代码更难被他人读懂。

如果操作系统的内存分配方式确实不能满足你的性能要求，不做优化的程序效率得不到满足。我的建议是，如果程序不是很特别的应用Hoard和TCmalloc这些第三方内存管理库就很好了，只要在链接时稍微费点心思就能解决内存性能的问题。

如果你膝盖中了一箭后，程序的可靠性或者应用场景有特殊的要求，非得用自己的代码进行内存管理，也可以自己写内存池，但这这个内存池一定要对其它透明，也就是说使用内存管理的函数不需要知道你内存管理的细节，管你是用哈希表、链表还是神马堆，它只要malloc和free就可以了。再考虑到内存管理的瓶颈可能不是在一个模块上，这种做法对整体的内存优化也是很方便的。