這是更有效的關於常數非常依賴。一方面,trie爲插入所有元素提供了嚴格的時間複雜度O(N)
,而在最壞的情況下,散列表可能衰減到二次時間。
在另一方面,嘗試都不是很有效的,當談到cache - 每個尋求需要O(|S|)
隨機存取內存請求,這可能導致性能顯著衰減。
這兩種方法都是有效的,我認爲在選擇一種方法時需要考慮多種因素,如最大latency(如果是實時系統),吞吐量和開發時間。
如果平均情況下性能是重要的,我會建議生成一堆文件,並運行statistical analysis哪種方法更好。簽名測試是使用中的藝術假設測試的事實上的狀態。
關於嵌入式系統:這兩種方法仍然是有效的,但在這裏: 在特里樹的每個「節點」(或一羣節點)將在磁盤上而不是在RAM中。請注意,這意味着對於特洛伊O(| S |)隨機訪問每個項目的磁盤查詢,這可能是緩慢的。
哈希計算解決方案,您有10MB,讓我們說,他們可以使用5MB出這些爲指針到磁盤的哈希表。假設您可以在這5MB存儲500個不同的磁盤地址(這裏是悲觀分析),這意味着每次哈希查找後您都剩下5MB的時間來加載一個存儲桶,並且如果您有500個存儲桶,並且負載因子爲0.5,則表示您可以存儲500 * 5MB * 0.5〜1.25GB> 1GB的數據,因此使用散列表解決方案,所以使用散列表- 每次查找將只需要O(1)
隨機磁盤查找爲了查找包含相關字符串。
請注意,如果它仍然不夠,我們可以重新掃描指針表,這與虛擬內存機制中的paging table中正在執行的操作非常相似。
由此我們可以得出結論,對於嵌入式系統,散列解決方案對於大多數情況下更好(注意它可能仍然遭受最壞情況下的高延遲,這裏沒有銀彈)。
PS,radix tree通常是更快和更緊湊然後特里結構,但是從字典樹的相同的副作用比較對散列表的受到(雖然少顯著當然)。
粗略地說,你期望在1GB文件中有多少不同的單詞? – NPE
我並不特別期待任何事情。這個問題可以用現實世界的術語來重新編寫,如從搜索列表或類似的東西中找到前10個搜索條件,所以我想它會遵循某種概率分佈,但我沒有設置特定的搜索條件。 – user1921187