|
telha wrote: but hashtable is faster in retrieval
Do you have any source to back that up?
The HashTable has a lot of additional code for handling thread safety, which of course slows down the process a bit, but other than that they seem to work pretty much the same.
Besides, once you have retrieved the value from the HashTable, you have to cast it, which you don't need to do with a Dictionary.
Despite everything, the person most likely to be fooling you next is yourself.
|
|
|
|
|
Thanks Guffa,
Guffa wrote: The HashTable has a lot of additional code for handling thread safety
Do you mean Hashtable is a class of thread safety?
regards,
George
|
|
|
|
|
Yes, HasTable is a synchronised collection, while Dictionary isn't.
Despite everything, the person most likely to be fooling you next is yourself.
|
|
|
|
|
|
Thanks Muhammad,
Happy to learn new things from you. Two more comments,
1.
telha wrote: Well MSDN states that Dictionary(Of TKey, of tValue) is a new class in v2.0. but further explains that the Objects used as Key are required to have an implementation of Equality Comparer, IEqualityComparer whereas in HashTable the objects used as Keys are required to override the IHashCode Provider interface or Object.GetHashCode method.
I did some search from MSDN, I think Dictionary is using either IEqualityComparer.Equals or System.IEquatable, while Hashtable is using Object.GetHashCode to check whether two keys' are the same?
2.
From, http://msdn.microsoft.com/en-us/library/xfhwa508(VS.80).aspx[^]
What means "Every key in a Dictionary must be unique according to the dictionary's equality comparer" -- I understand key in a Dictionary should have an equality comparer, but I do not know what means an equality comparer for a Dictionary itself?
regards,
George
|
|
|
|
|
George_George wrote: I did some search from MSDN, I think Dictionary is using either IEqualityComparer.Equals or System.IEquatable, while Hashtable is using Object.GetHashCode to check whether two keys' are the same?
Both the HashTable and the Dictionary uses both the GetHashCode method and some kind of comparer. The hash code is used to determine a bucket for the item, and the comparer is used when looping through the items in the bucket to find the correct item.
HashTable uses the Equals method if no customer key comparer is specified. Dictionary uses the default EqualityComparer for the key if no custom key comparer is specified.
George_George wrote: What means "Every key in a Dictionary must be unique according to the dictionary's equality comparer" -- I understand key in a Dictionary should have an equality comparer, but I do not know what means an equality comparer for a Dictionary itself?
That's the same thing. The equality comparer for the dictionary is only used to compare keys.
Despite everything, the person most likely to be fooling you next is yourself.
|
|
|
|
|
Great Guffa!
1.
Guffa wrote: The hash code is used to determine a bucket for the item, and the comparer is used when looping through the items in the bucket to find the correct item.
If more then one elements falls into the same bucket (I think it means hashing conflicting), from your reply, it seems the elements of the same bucket is sorted using Comparer?
2.
Guffa wrote: That's the same thing. The equality comparer for the dictionary is only used to compare keys.
From the Key type, we can implement the type from equality class, but how to assign the equality cmoparer for the Dictionary itself?
regards,
George
|
|
|
|
|
George_George wrote: If more then one elements falls into the same bucket (I think it means hashing conflicting), from your reply, it seems the elements of the same bucket is sorted using Comparer?
The elements are not sorted, they are just placed in buckets and the order in a bucket is not defined.
The comparer is always used when retrieving items. First the bucket is determined from the hash code, then the comparer is used to compare the desired key with the keys of the stored items (even if there is only one in the bucket).
George_George wrote: From the Key type, we can implement the type from equality class, but how to assign the equality cmoparer for the Dictionary itself?
You can specify a comparer in the constructor to the dictionary. I actually wrote an article about that:
Dictionary with a Custom Key[^]
Despite everything, the person most likely to be fooling you next is yourself.
|
|
|
|
|
Hi Guffa,
I take some time to study your article. It is not big, but clear enough, cool! I like it! 
A few comments,
1.
Why you use inner class to implement the comparer interface? Why not just let the parking special key class implements the comparer interface directly? Any benefits?
2.
I want to confirm with you that,
when we use Hashtable, Object.Equals and Object.GetHashCode is used. But when we use Dictionary, IEqualityComparer.Equals and IEqualityComparer.GetHashCode is used?
3.
Equality comparer of the Dictionary is what is used as the 1st parameter of the Dictonary constructor, like your inner class ParkingSpaceKey.EqualityComparer?
regards,
George
|
|
|
|
|
|
Thanks Alan,
I think it is more correct to say Hashtable is a special type of Dictionary, whose key type is Object, correct?
regards,
George
|
|
|
|
|
I think it's the other way around. A hashtable is a specific type of data structure whose key can be anything that can be represented as binary.
A Dictionary is an object that performs a function, and it can be implemented with a hashtable or other data structures. Often you see this functionality implemented with a red-black tree which can grow dynamically (e.g. in C++'s STL), as opposed to a hashtable which has a fixed size.
|
|
|
|
|
Thanks Alan,
Alan Balkany wrote: as opposed to a hashtable which has a fixed size.
You mean Hashtable does not grow? I think when we insert elements into Hashtable, it grows.
Any comments?
regards,
George
|
|
|
|
|
A hashtable has a fixed size. When it gets too full its performance degrades, so one strategy is to then create a bigger one, and reinsert all the elements into it.
This has some overhead. Normally a hashtable allows insertion and retrieval in constant time. When the hashtable has to grow regularly, it can increase the time for insertion to O(n) or higher, depending on how often it happens.
|
|
|
|
|
Thanks Alan,
1.
Alan Balkany wrote: A hashtable has a fixed size. When it gets too full its performance degrades, so one strategy is to then create a bigger one, and reinsert all the elements into it.
I am confused what do you mean fixed size. I think from developer point of view, we can insert as much elements as possible into Hashtable, so no feel of limitation of fixed size. Any more descriptions or pseudo code please?
2.
Alan Balkany wrote: When the hashtable has to grow regularly, it can increase the time for insertion to O(n) or higher, depending on how often it happens.
What means grow regularly? Why the performance degrades? Could you provide more description please?
(reference document link is also ok, I am interested in this topic)
regards,
George
|
|
|
|
|
Here's link that explains more: http://en.wikipedia.org/wiki/Hash_table[^]
Hashing transforms a key into the address of a slot to store the data in. There are a fixed number of slots. When multiple keys are mapped to the same slot, there are different ways of handling it, all of which take time.
Type "hash table" into Google, and you'll get much more than I can explain here.
|
|
|
|
|
How about my question item 1?
--------------------
I am confused what do you mean fixed size. I think from developer point of view, we can insert as much elements as possible into Hashtable, so no feel of limitation of fixed size. Any more descriptions or pseudo code please?
--------------------
Fixed size means limited size?
regards,
George
|
|
|
|
|
Look at the link I gave, type "hash table" into Google and look at some of those references, and see if they answer your questions. There's a lot of material on hash tables out there, with more complete explanations than I can give you here.
|
|
|
|
|
Thanks Alan,
I read the link, clarified a lot of things. I often heard people talk about re-hash, does it mean the same thing of "Table resizing" in the link you mentioned?
regards,
George
|
|
|
|
|
It might. I haven't heard that term in the context of hash tables.
|
|
|
|
|
Thanks Alan,
Your reply is clear. I want to check why do you think before Hashtable is fixed size? If the load factor is large enough (e.g. HashMap in Java is 75%), it will be resized to increase its size -- so not fixed. Could you clarify please?
regards,
George
|
|
|
|
|
If you increase the size of the hash table, you also have to change the hashing function to produce keys for this larger size. When you do this, the elements you've already added to the hash table must go to different slots. So every element must be re-inserted in the new larger table.
This process creates a new hash table and replaces the old one. The old one wasn't resized.
|
|
|
|
|
Thanks Alan,
So, the root cause is hash function is dependent on table size? 
regards,
George
|
|
|
|
|
|
Thanks Alan!
You mentioned before -- "When the hashtable has to grow regularly, it can increase the time for insertion to O(n) or higher, depending on how often it happens.". "It" means?
regards,
George
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
