寄せられる感想メールに多い「軽い」「速い」そして「なぜ？」にお答えします。

まず、「軽い」ですが、これは単にマルチスレッドでの検索を行うようにして、検索中も操作を受け付けるようにしているためにそのように感じるのではないか、と言うことで納得して下さい。処理中に「待ち状態」にならず、制限付きでも操作を受け付ける状態というのは使ってみると、「軽く」感じるものなんです。

で、「速い」理由ですが、F_CHKで採用しているアルゴリズムを基本的な部分で流用していますので、それを解説しましょう。
検索は以下の順序で行われます。

1. 指定された箇所のすべてのファイルを羅列
2. 羅列したファイルをファイルサイズ順に並べ替える
3. ファイルサイズが同じものを比較し、一致したものを表示する

次のような感じでファイルがあったとします（ファイルサイズはすべて同じとする）。

ファイル名	ファイルのタイプ	一致状況
ファイル１	テキスト	☆
ファイル２	プログラム	◎
ファイル３	テキスト	☆
ファイル４	テキスト	☆
ファイル５	MIDIファイル
ファイル６	プログラム	◎
ファイル７	HTML
ファイル８	WAV

一致状況に書かれている記号が同じもの同士が内容が一致しているとしてF_CHKとSAME_Fで採用しているアルゴリズムでの比較をしてみましょう。

本来ファイルタイプなんて関係ないんですが、説明しやすくするためにあげておきました。

既に気力の持たない状態になってますね。
そこで、人間様の考えるような方法で比較します。

STEP1 ファイル１との比較

ファイル１とファイル２〜ファイル８までをとりあえず全部読み込んで比較します。この比較自体は省略できないので仕方ありません。
この時点ではファイル１とファイル３とファイル４が一致していることがわかります。

また、このとき、ファイルの内容をもとにちょっとした計算をして各ファイルの特徴を捉えておきます。

ファイルの特徴・・・・簡単に言えばファイルの中のデータを１６進数としてそのまま合計しているような感じだと思って下さい。実際には単純な合計ではありませんが、ある程度特徴を捉えやすいように計算しています。また、この計算は最初にファイルを読み込んだときに行って、結果を記憶しておきます。

STEP2 ファイル２との比較

ファイル２とファイル３〜ファイル８の比較をしますが、STEP1と違う動きをします。
ファイル２とファイル３を比較しようとするのですが、ファイル３は既にファイル１と内容が一致していますし、ファイル２とファイル１は一致していません。

つまり、

ファイル４についても同様のことが言えるので、次へ。

そしてファイル５と比較です。
ファイル５は今のところファイルとも一致していませんので、まず、STEP1で計算しておいた「ファイルの特徴」を比較します。このとき、「ファイルの特徴の値」はファイルの内容が同じなら全く同じですが、ファイルの内容が違う場合、かなり高い確率で違う値になります（そうなるように工夫して計算いるつもりです）。
ファイル２はプログラムファイルでファイル５はMIDIファイルですから違う値になっている可能性が非常に高くなります。

逆に言えば同じ種類のファイルは同じ値を持つことも多くなるので、影響の出にくいように調整しています。

ファイル６との比較はきちんと行います。

ファイル７，ファイル８はおそらくわざわざ読み込んで比較することはしません。

STEP3 ファイル３との比較

ファイル３とファイル４〜ファイル８の比較です。
しかし、ファイル３とファイル４はファイル１と内容が一致していますので、

そしてファイル５〜ファイル８ですが、

以降、同様の手順で比較をしていこうとしますが、比較する可能性のあるのは

• ファイル５とファイル７
• ファイル５とファイル８
• ファイル７とファイル８

すると処理全体を通して、ファイルの内容を読み込むのは最低８回多くて１４回。
これに対して全部総当たりで読み込んだ場合、読み込み回数は２８回。

最大で３分の一、最悪の場合でも半分の読み込み回数でファイルの比較が終了してしまいます。
ある程度検索対象のファイルの内容に依存する部分がありますが、ファイルの読み込み回数が減ると言うことは処理時間が短くなるって事に繋がるので、結構効果があるんじゃないかな〜と思ってこんなアルゴリズムを採用しています。

人の手で比較するのと非常によく似た方法で比較しているので思いついたときには画期的だったのですが、