為什麼雜湊訪問比較快?使用它需要付出什麼代價

2022-09-26 05:51:15 字數 2854 閱讀 2063

雜湊表和雜湊函式是大學資料結構中的課程,實際開發中我們經常用到hashtable這種結構,當遇到鍵-值對儲存,採用hashtable比arraylist查詢的效能高。為什麼呢?我們在享受高效能的同時,需要付出什麼代價(這幾天看紅頂商人胡雪巖,經典台詞:在你享受這之前,必須受別人吃不了的苦,忍受別人受不了的屈辱),那麼使用hashtable是否就是一樁無本萬利的買賣呢?就此疑問,做以下分析,希望能拋磚引玉。

一、hash它為什麼對於鍵-值查詢效能高

學過資料結構的,都應該曉得,線性表和樹中,記錄在結構中的相對位置是隨機的,記錄和關鍵字之間不存在明確的關係,因此在查詢記錄的時候,需要進行一系列的關鍵字比較,這種查詢方式建立在比較的基礎之上,在.net中(array,arraylist,list)這些集合結構採用了上面的儲存方式。

比如,現在我們有乙個班同學的資料,包括姓名,性別,年齡,學號等。假如資料有

姓名性別

年齡學號張三男

151李四女

142王五男

143

假如,我們按照姓名來查詢,假設查詢函式findbyname(string name);

1)查詢「張三」

只需在第一行匹配一次。

2)查詢"王五"

在第一行匹配,失敗,

在第二行匹配,失敗,

在第三行匹配,成功

上面兩種情況,分別分析了最好的情況,和最壞的情況,那麼平均查詢次數應該為 (1+3)/2=2次,即平均查詢次數為(記錄總數+1)的1/2。

儘管有一些優化的演算法,可以使查詢排序效率增高,但是複雜度會保持在log2n的範圍之內。

如何更更快的進行查詢呢?我們所期望的效果是一下子就定位到要找記錄的位置之上,這時候時間複雜度為1,查詢最快。如果我們事先為每條記錄編乙個序號,然後讓他們按號入位,我們又知道按照什麼規則對這些記錄進行編號的話,如果我們再次查詢某個記錄的時候,只需要先通過規則計算出該記錄的編號,然後根據編號,在記錄的線性佇列中,就可以輕易的找到記錄了 。

注意,上述的描述包含了兩個概念,乙個是用於對學生進行編號的規則,在資料結構中,稱之為雜湊函式,另外乙個是按照規則為學生排列的順序結構,稱之為雜湊表。

仍以上面的學生為例,假設學號就是規則,老師手上有乙個規則表,在排座位的時候也按照這個規則來排序,查詢李四,首先該教師會根據規則判斷出,李四的編號為2,就是在座位中的2號位置,直接走過去,「李四,哈哈,你小子,就是在這!」

看看大體流程:

從上面的圖中,可以看出雜湊表可以描述為兩個筒子,乙個筒子用來程式設計客棧裝記錄的位置編號,另外乙個筒子用來裝記錄,另外存在一套規則,用來表述記錄與編號之間的聯絡。這個規則通常是如何制定的呢?

a)直接定址法:

我在前一篇文章對gethashcode()效能比較的問題中談到,對於整形的資料gethashcode()函式返回的就是整形   本身,其實就是基於直接定址的方法,比如有一組0-100的資料,用來表示人的年齡

那麼,採用直接定址的方法構成的雜湊表為:01

2345

0歲1歲

2歲3歲

4歲5歲

.....

這樣的一種定址方式,簡單方便,適用於元資料能夠用數字表述或者原資料具有鮮明順序關係的情形。

b)數字分析法:

有這樣一組資料,用於表述一些人的出生日期年月

日75101

7512

1075

0214

分析一下,年和月的第一位數字基本相同,造成衝突的機率非常大,而後面三位差別比較大,所以採用後三位

c)平方取中法

取關鍵字平方後的中間幾位作為雜湊位址

d)摺疊法:

將關鍵字分割成位數相同的幾部分,最後一部分位數可以不相同,然後去這幾部分的疊加和(取出進製)作為雜湊位址,比如有這樣的資料20-1445-4547-3

可以        5473

+      4454

+        201

=    10128

取出進製1,取0128為雜湊位址

e)取餘法

取關鍵字被某個不大於雜湊表表長m的數p除后所得餘數為雜湊位址。h(key)=key mod p (p<=m)

f)隨機數法

選擇乙個隨機函式,取關鍵字的隨機函式值為它的雜湊位址,即h(key)=random(key) ,其中random為隨zowiy機函式。通常用於關鍵字長度不等時採用此法。

總之,雜湊函式的規則是:通過某種轉換關係,使關鍵字適度的分散到指定大小的的順序結構中。越分散,則以後查詢的時間複雜度越小,空間複雜度越高。

二、使用hash,我們付出了什麼?

hash是一種典型以空間換時間的演算法,比如原來乙個長度為100的陣列,對其查詢,只需要遍歷且匹配相應記錄即可,從空間複雜度上來看,假如陣列儲存的是byte型別資料,那麼該陣列占用100byte空間。現在我們採用hash演算法,我們前面說的hash必須有乙個規則,約束鍵與儲存位置的關係,那麼就需要乙個固定長度的hash表,此時,仍然是100byte的陣列,假設我們zowiy需要的100byte用來記錄鍵與位置的關係,那麼總的空間為200byte,而且用於記錄規則的表大小會根據規則,大小可能是不定的,比如在lzw演算法中,如果乙個很長的用於記錄畫素的byte陣列,用來記錄位置與鍵關係的表空間,演算法推薦為乙個12bit能表述的整數大小,那麼足夠長的畫素陣列,如何分散到這樣定長的表程式設計客棧中呢,lzw演算法採用的是可變長編碼,具體會在深入介紹lzw演算法的時候介紹。

注:hash表最突出的問題在於衝突,就是兩個鍵值經過雜湊函式計算出來的索引位置很可能相同,這個問題,下篇文章會令作闡述。

注:之所以會簡單得介紹了hash,是為了更好的學習lzw演算法,學習lzw演算法是為了更好的研究gif檔案結構,最後,我將詳細的闡述一下gif檔案是如何構成的,如何高效操作此種型別檔案。

本文標題: 為什麼雜湊訪問比較快?使用它需要付出什麼代價

本文位址: /ruanjian/csharp/153706.html

雜湊是什麼?為什麼雜湊訪問比較快?

本內容為本人學習 大話 資料結構 一文的總結摘要 雜湊演算法訪問之所以快,是因為其 直接通過關鍵字key得到要訪問的記錄記憶體儲存位置 試想這樣的場景,你很想學太極拳,聽說學校有個叫張三丰的人打得特別好,於 是你到學校學生處找人,學生處的工作人員可能會拿出學生名單,乙個乙個的查詢,最終告訴你,學校沒...

雜湊是什麼?為什麼雜湊訪問比較快?

不太恰當的比喻 xm 指的是 小明 也指的是 小萌 xm就是雜湊值,小明和小萌就是擁有同乙個雜湊值的,存在同乙個鍊錶的元素。想要獲取小萌,首先使用hashcode獲取到這兩個人,然後再通過equals獲取到小萌。個人理解 雜湊表其實就是乙個一維陣列,而陣列中的每乙個元素都是乙個單向鍊錶而已。這樣的資...

alloca 是什麼?為什麼不提倡使用它?

alloca 是什麼?為什麼不提倡使用它?在呼叫alloca 的函式返回的時候,它分配的記憶體會自動釋放。也就是說,用alloca 分配的內存在某種程度上區域性於函式的 堆疊幀 或上下文中。alloca 不具可移植性,而且在沒有傳統堆疊的機器上很難實現。當它的返回值直接傳入另乙個函式時會帶來問題,如...