ある文字列が、特定の文字列(辞書)の中に含まれているかどうかを効率よく調べる手法です。これだけだと何を言っているのかわかりませんね。具体的には以下のように動作します。0とする)を用意し、登録したい単語を辞書に登録して行きます。k個のビットフラグ(1)を立てて行くだけ。1だと含まれると判断する)事で容易に判別できます。使う事で、辞書サイズをかなり小さくする事ができ、検索も一瞬。良い事尽くめのように見えますが、いくつか弱点があります。100%保証できません。いう事かと言うと、k個の関数を通した結果が、偶然すべて一致する単語が複数あった場合は、それらを区別できずどちらも「辞書に含まれている」としてしまいます。あとは、辞書への追加は可能ですが、削除はできません。削除したい場合は辞書を作り直す事になります。ビット列が1で埋まって行き、間違える可能性が高くなります。誤検知の確率は下がるものの、結局はメモリとのトレードオフになります。すると、それぞれの数によって誤検知率は変わってきます。事前にそれらを計算した表がありました。なり、100,000単語に付き一回間違えるとかそんな感じでしょうか。ページが無かったとしたらそれは誤検知です。開き直ってそのページを作る等の対応をお願いします。ついて調べた際、分かりやすかったのは以下のページです。BloomFilter高速化と政教分離の歴史さて、形態素解析と辞書は準備できました。するとあとは一ページを解析するのにかかる時間をいかに短くできるかです。最初は、DOMで全てのテキストノードを取得し、ちまちま置換して行っていたのですが、ページが大きくなるといまいち待たされる。これは考えうる最大のページを参考に、それをベンチマークにしようと思い、探すとこんなものを見つけました。計算ライブラリを入れ替えたりいろいろやってみたものの劇的な効果は得られず。恐るべし政教分離の歴史。違いなんかを調べたりしていたのですが、そこで閃いた。遅くなってもキャンセルできるし、ブラウザが固まる事はないんじゃね?ここでヒントになったのは小飼弾さんのこの記事です。5倍になりましたが、リアルタイムで処理状況が分かるので時間はあまり気にならなくなりました。処理中もブラウジングできるし、プログレスメニュー(左下に出るパーセント表記ね)も表示するようにしたし。しても何か遅いので、こんなのを使ったりとか。delayこれは結構効果的でした。5分くらいかかるんですけどね。途中でキャンセルできるようにしたから許して。フレームとの戦いあと困ったのがフレームを使ったページの場合。使いまくりのくせにこんなことを言うのもなんですが、フレームページは扱いにくい。orz正確に言うと埋め込みはできるんだけど、普通にやると全フレームにメニューを埋め込んじゃう。これじゃいかんという事で、いろいろ考えた結果、フレームページの場合は、Pediatorメニュー用にもう一つフレームを作るという力技で対処しました。プログレスメニュー表示は諦め。プログレスメニューを出さないので、フレームを使ったページの場合は、一気に書き換えるようになっています。引っかかるような感じはあるけど、まあこれはこれで。いやほんと、フレームとかなくなればいいのに。辞書は気が向いた時に更新します。コメントをキャンセルメールアドレスが公開されることはありません。