D2009更快的CompareText实现

Question

我在我的程序中广泛使用哈希映射数据结构。我在Codegear论坛上发布了Barry Kelly使用的哈希映射实现。该实现内部使用RTL的CompareText函数。分析使我意识到，很多时间都花在了SysUtils CompareText函数中。

我看看

Fastcode site

，发现CompareText的快了一些实现。不幸的是，它们似乎不适用于D2009及其Unicode字符串。

现在问题：是否有支持D2009字符串的类似更快的版本？ CompareText函数在使用哈希映射时似乎被称为很多（至少在我目前使用的实现中），所以很少有性能改进可以真正发挥作用。或者应该在那里提供的实现也适用于unicode字符串？

Answer 1

许多FastCode函数可能会在Delphi 2009中编译并显示工作得很好，但它们不适合所有输入。那些在汇编器中实现的将会失败，因为它们假定字符每个只有一个字节。在Delphi中实现的那个会更好一些，但是它们仍然会返回不正确的结果，因为旧的CompareText的“不区分大小写”的概念是基于ASCII的，而新的应该基于Unicode。字符被认为是相同的规则除外大小写是对于Unicode来说，它们的许多不同于它们对ASCII的方式。

Andreas在下面的评论中说，Unicode CompareText仍然使用ASCII大小写比较规则，所以许多FastCode函数应该可以正常工作。在使用它们来确保它们没有做出任何字符大小的假设之前，请先查看它们。我似乎记得一些 FastCode功能已被纳入Delphi RTL。我不知道CompareText是否是其中之一。

如果你在一个散列表中打电话CompareText很多，那么这表明你的散列表没有做很好的工作。 CompareText只应在您搜索的内容的散列指定散列表中的非空桶时才被调用。从那里，哈希表通常会使用线性搜索来查找存储桶中的正确项目，并在该搜索期间为每个项目调用CompareText。我不知道你是用这种方式工作的。

您可以通过使用不同的散列函数来解决此问题，该函数可将结果更均匀地分布在可用存储桶中。如果您的存储桶已经被均匀填充，那么您可能需要更多存储桶（然后确保散列功能仍然均匀分布在，即数字）。

如果您使用的哈希映射类是基于TBucketList，那么存储桶存储空间还有待改进。该类不会计算整个输入的散列值。它使用输入只有来确定要使用的存储桶。如果该类还将跟踪为字符串计算的完整散列值，则线性搜索过程中的比较可能会更快。只需比较哈希，并且只在哈希匹配完全时比较字符串。 （对于一个256桶的桶列表，最大支持的大小，只有一个字节的输入决定桶，其余的字节被忽略。）I've written about TBucketList here before.