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.