哈希表和套管

本文介绍了哈希表和套管的处理方法，对大家解决问题具有一定的参考价值，需要的朋友们下面随着小编来一起学习吧！

问题描述

做一个大量使用域名的项目，例如

" www.yahoo.com。"

域名保留案例但是如果相同则名称相同，但是

情况不同。

我知道我可以将这些名称存储为带有大小写的哈希表中的键

comparer和CaseInsensitiveHashCodeProvider 。这很好。好处

是我可以存储域名而不用担心案例并返回用户

提供的案例而不存储状态等。但是，这需要付出代价

因为现在所有的字符串比较操作都必须区分大小写，例如

endswith等等。如果大小写都是更低的话。例如，字符串比较非常快，如果实习，那么真的很快。我可以将域名存储为所有

小写，然后存储一个bitArray，告诉我哪些字符在哪里上面

的情况。然而，这似乎是一个痛苦，仍然需要至少32字节

为255个字符的域名，或3字节为20个字符名称。我还可以

将原始案例存储为字符串，并使用小写版本

用于所有比较，结束，散列等操作。然而，这需要两倍的存储空间。对于

重复项，可以使用字符串实习。这是我在性能方面最具吸引力的选择我认为，但是想知道别人怎么想？干杯！

-

William Stacey，MVP

Doing a project that makes heavy use of domain names such as
"www.yahoo.com."
Domain names preserve case but are concidered equal if names are same but
case is different.
I know I can store these names as keys in a hashtable with case insens
comparer and CaseInsensitiveHashCodeProvider. That works fine. The benifit
is I can store the domain name and not worry about case and return the user
supplied case without storing an state, etc. However, this comes at a cost
because all string compare operations now must be case sensitive such as
endswith, etc. If case was all "lower" for example, string compares is very
fast and if interned, then really fast. I could store domain name as all
lower case and then store a bitArray that tells me what chars where upper
case. However that seems like a pain and still requires at least 32 bytes
for a 255 char domain name, or 3 bytes for a 20 char name. I could also
store both the original case as a string and the lower case version that is
used for all compare, endswith, hash, etc operations. However this doubles
the storage needed. This can be leveraged with string interning for
duplicates. That is my most attractive option in terms of performance I
think, but was wonder what others think? Cheers!

--
William Stacey, MVP

benifit

哈希表和套管

问题描述

推荐答案