  |
http://anond.hatelabo.jp/20090326142330 の続き
pythonでベンチとった。試した方法は以下
長くなるので、使用したスクリプトと生の結果は http://anond.hatelabo.jp/20090326123924 に貼った。
結果としては、早さは3, 4, 1, 2の順で、３を基準にとると、
| 文字列長 | md5hex | crc32x4 | headtail | skipover | ループ回数 |
|---|---|---|---|---|---|
| 256 | 6.6 | 36 | 1.0 | 1.4 | 65536 |
| 1024 | 8.3 | 36 | 1.0 | 2.0 | 16384 |
| 4096 | 26 | 85 | 1.0 | 2.5 | 4096 |
という比率になった。
文字列長が長くなるとやはり後2つが有利だ。また、今回は32文字に切り詰めたがそれでもコリジョンは発生しなかった。アルゴリズム上、数文字だけの変化には対応出来ない可能性があるが、切り詰める量が少なく入力にいくらかのランダム性があれば実用になると思う。
(追記：URLで使ったら、ランダム性が悪くてコリジョン出た。素直にmd5がベターかもしれない)
しかし、この程度の速度差であれば、コリジョン耐性を重視して素直にmd5を使用するのも良いかもしれない。特に、今時はネイティブコードのライブラリをほぼ標準で持つ処理系が多いため、まずはmd5で、としても間違いはなさそう。
セキュリティ目的ではない。ハッシュテーブルで使うような奴でキャッシュで使いたい。 手軽なほうが良い。軽いほうが良い。推測可能でよい。数十バイトくらいの文字列にしたい。 md5...
ただの連番でよくね？
連番ってどういうこと？ 順方向に探査すれば？ってこと？ 何に使いたいか具体的に書くと、とある処理でwebページを取得するのだけど、その時、urlをキーにmemcachedでキャッシュしよう...
URLの最初の100文字程度と、最後の100文字程度をくっつけたとしたら、実際に使われているURLでは殆ど衝突しないのではないだろうか？
頭１００バイトと尻１００バイトで思いついたけど、網目キャッシュなんてどう？ あらかじめ250バイトって制約があるなら、 ・250バイトまでの文字列はそのまま ・250バイトを超えたら...
確かにそんな気はする。つか、前はほぼ固定なので、後250を取れば問題ない気がする。 ただ、今後の事も考えて、ベターな方法を知っておこうかなと。
適当にググる。がいくつかあったので羅列 某所のハッシュテーブル実装のおまけ的ハッシュ値計算法 str.charCodeAt(0) + str.charCodeAt(str.length-1)(str.charCodeAt(0) + str.charCodeAt(str.length-1)) * str.length...
11
