我正在使用 ARM 设备上的实时应用程序。性能很重要,所以我使用了一个通用的 ObjectPool 类。
到目前为止,我会将池预分配到我可以预期的最大大小,但现在我遇到了我绝对必须调整池大小的情况。
在查看了围绕网络和 SO 的许多解决方案后,我注意到调整大小始终是触发 GC 的数组复制操作。我认为这没问题,但现在开始看到性能影响确实很重要。
是否有真正的可调整大小的对象池解决方案/模式产生零垃圾?
我正在使用 ARM 设备上的实时应用程序。性能很重要,所以我使用了一个通用的 ObjectPool 类。
到目前为止,我会将池预分配到我可以预期的最大大小,但现在我遇到了我绝对必须调整池大小的情况。
在查看了围绕网络和 SO 的许多解决方案后,我注意到调整大小始终是触发 GC 的数组复制操作。我认为这没问题,但现在开始看到性能影响确实很重要。
是否有真正的可调整大小的对象池解决方案/模式产生零垃圾?
我会编写一个在内部使用链表的对象池。这将允许您的池增长到需要的大小。并且池应该从该链表的开头添加和删除。反过来,这将保证在压力较低时重复使用相同的对象。
另一方面,构建和/或拆除这些对象是否昂贵?因为首先使用池的一个原因是管理创建和销毁昂贵的对象。
使用池的另一个关键原因是重用对象,您几乎总是从池中获取第一个对象,并希望这些对象在 cpu 缓存中可用。您用完池中的对象这一事实表明您不会从拥有该池中受益匪浅。
所以我的建议是在你开始对一个新的对象池进行编码之前,也许你应该尝试删除这个池,看看当你让 GC 发挥它的魔力时它会如何影响性能。