我的应用程序大量使用TList,所以我想知道是否有更快或针对特定用例优化的替代实现.
我知道RtlVCLOptimize.pas 2.77,它已经优化了几种TList方法的实现.
但是我想知道那里还有什么.我也不要求它是TList后代,我只需要TList功能,无论它是如何实现的.
考虑到TList提供的相当基本的功能,完全有可能没有太大的改进空间,但仍然需要验证,因此这个问题.
编辑：在我的特定用例中,没有列表被排序.有很多列表,其中包含了不同数量的元素.我确实用自己的类替换了TList,以便记录添加/删除调用的数量和元素的数量.它报告(所有列表的toatal)：
ListAdd = 15766012; ListRemove = 10630000; ListCount = 5136012
我还可以找出单个列表中元素数量最多的是什么.
我没有特别的问题,我只是想知道是否有办法让它更快,因为这些数字甚至小的改进会加起来.
解决方法
我对TList知道的最大瓶颈之一是大型列表中的删除/提取.删除项目[0]比删除项目[计数-1]慢得多,因为它后面的内存移动.
例如,在包含65536个元素的列表中：
while list.Count > 0 do List.Delete(0) //Takes 2 mins to complete for I := List.Count-1 downto 0 do List.Delete(I) //Takes less than 1 sec
因此,如果您有一个包含数百万个元素的TList,删除一个低索引项可能在性能上是昂贵的.此外,考虑到列表未排序会导致在其中找到元素的速度非常慢. IndexOf在大型列表上非常慢.您可能需要考虑保持列表排序.
此外,考虑到您的项目数量可能非常大,您可能需要考虑使用TList列表来存储元素,这将有助于减少我已经提到的删除/提取开销.