HashMap和Trie樹的比較?

時間 2021-06-17 18:52:17

1樓:

個人淺見,就openjdk而言HashMap的查詢效率並不是O(1)。

查詢首先要計算查詢物件的hashcode,而String物件的hash成員是"懶漢"式的,延遲到你呼叫hashcode方法時才儲存下來。

而點進String物件的hashcode原始碼,可以發現hashcode的計算需要遍歷字串的每乙個字元。

所以HashMap與Trie在查詢字串上,如果被查詢物件的hashcode從未計算過,效率其實一樣,需要遍歷被查詢物件的每個字元。

但是在msvc中,微軟對字串雜湊的實現方式是O(1),所以雜湊複雜度多少還得看原始碼,stackoverflow對此有精彩的回答,可以移步查閱。

2樓:Hagoop Coder

最基本的用處不一樣。Trie在字首查詢方面應用是要比hashmap快的多的。舉個栗子,你有一篇動漫分析文章,外加乙個動漫人物名稱字典dict,怎麼從文章中直接把所有動漫人物爬出來。

如果你要用hashmap(或者hashset),最基本的用法就是把動漫人物名全存到map或者set裡,掃瞄文章的每乙個字,以這個字為人名開頭,向後搜尋若干位,知道最大人名長度,如果hashset裡都沒有的話,掃瞄下乙個字作為人名開頭。可以發現巨慢無比,時間複雜度O(mn)。用trie的話不用重複搜尋,複雜度O(n)可以實現。

3樓:Dante

完全不一樣的東西

HashMap 實現的是雜湊表,用於解決O(1)的精確查詢,無論是記憶體中實現程式邏輯還是外存中實現 key - value 儲存,幾乎無處不用

Trie 樹即字典樹,用於解決字首檢索(模糊查詢),最經典的應用就是搜尋 suggest,搜尋"變形",suggest 給你"變形金剛"

從 Trie 當然也能演化出字尾樹,解決字尾檢索問題Trie 能解決 HashMap 的問題(精確檢索本來就是模糊檢索的乙個特例),只不過速度沒 HashMap 快(這個你已經知道了)

HashMap 不能解決 Trie 的問題

4樓:毛偉

視力沒救了,把題目看成HashMap和TreeMap的比較……醞釀半天發現問的是Trie樹……

老實說,作為乙個民工,以前都不知道Trie樹這種結構,不過剛才一頓亂搜還是看到一些結論了:

雷鵬:trie樹這個資料結構的優點是什麼,中文名稱是什麼? 提高點難度:他的缺點是什麼,效率用big O表示是多高?

Trie key/value store implementation comparing with HashMap

乙個共同的結論就是Trie樹速度更快,但是記憶體空間開銷更大

How to implement a dictionary (Trie vs HashTable and important issues)?

這個回答裡提到一點:

A trie isnota general-purpose dictionary data structure. The reason is that a trie is a specialized search tree for (sub)string search.

trie不是乙個通用的資料結構,用途上更加專用於字串查詢

希望這能幫到你。

基於樹的adaboost和Gradient Tree Boosting區別?

楚子航 GBDT vs AdaBoost 相同點 加性模型 前向分步演算法 每一步訓練乙個弱學習器以彌補前面模型的不足2.不同點 AdaBoost中當前學習器的 不足 由樣本權重來決定GBDT中當前學習器的 不足 由求梯度決定梯度提公升樹 回歸樹 的演算法與原始的提公升樹 回歸樹 演算法的核心區別主...

Conflux的樹圖結構究竟有什麼優點和特別之處?

與中本聰共識在打包區塊時對交易順序進行嚴格規範不同,Conflux樂觀地假設,在並存的區塊中,交易 Tx,Transactions 是不衝突的,只要所有節點對一致的交易順序達成共識即可。基於這一假設,Conflux首先設立規則將區塊們集成為有向無環圖 DAG 每個區塊都需要引用乙個它的父區塊的邊 P...

為什麼感覺村上春樹的知名度比許多諾獎得主要高很多?

你的提問中已經部分給出了答案,就是感覺。因為我們的感覺是從本中國人的閱讀心態,日本作家天然對於我們是有親近感的,再加上村上的 挪威的森林 在本國的小資群體如此長盛不衰,所以知名度在本國是很高的。而部分答主提出諾獎作家若干年後有大半人不會有人去讀,這完全是從本國的閱讀心態上作的臆斷。誠然,諾獎作家中確...