每当您的应用程序具有性能密集型的关键路径时,就应该担心如何处理内存。大多数最终用户客户端应用程序不属于此类,因为它们是主要事件驱动的,并且大多数事件来自与用户的交互,并且没有那么多(如果有的话)性能约束。
但是,许多后端软件应将重点放在如何处理内存上,因为许多该软件可以扩展以处理更多数量的客户端,更大数量的事务,更多数据源...。突破极限,您可以开始分析软件用户的存储方式并编写针对您的软件量身定制的自定义分配方案,而不必依赖编写用于处理任何可想象的用例的完全通用的内存分配器。
仅举几例...在我成立的第一家公司中,我从事过Historian软件包的开发,该软件包负责收集/存储/存档过程控制数据(例如工厂,核电站或炼油厂,具有数百万个传感器,我们将存储该数据)。每当我们分析任何阻止Historian处理更多数据的性能瓶颈时,大多数时候问题就出在内存的处理方式上。我们已经竭尽全力确保除非绝对必要,否则不调用malloc / free。
在我目前的工作中,我从事监视视频数字记录器和分析程序包的工作。在30 fps下,每个频道每33毫秒接收一个视频帧。在我们出售的硬件上,我们可以轻松录制100个频道的视频。因此,这是确保在关键路径(网络调用=>捕获组件=>记录器管理软件=>存储组件=>磁盘)中没有任何动态内存分配的另一种情况。我们有一个自定义帧分配器,其中包含固定大小的缓冲区存储区,并使用LIFO重用先前分配的缓冲区。如果您需要600Kb的存储空间,则可能会得到1024Kb的缓冲区,这会浪费空间,但是由于它是专为我们的用途而量身定制的,因此每次分配的时间都很短,因此可以很好地工作,因为使用了缓冲区,
在我所描述的应用程序类型中(将大量数据从A移到B并处理大量的客户端请求)是往堆后移,这是CPU性能瓶颈的主要来源。将堆碎片保持在最低水平是第二个好处,但是据我所知,大多数现代OS已经实现了低碎片堆(至少我知道Windows可以,并且希望其他人也这样做)。就个人而言,在这些类型的环境中工作了12年以上,我经常看到与堆有关的CPU使用率问题,而我从未见过实际遭受过零散堆的系统的问题。