ジャストシステムのConceptSearchの体験版を使ってみています。
Googleデスクトップ検索は，鶴亀メールを使っている場合，いろいろウザイのです。具体的には「キャッシュをクリアしますか？」ダイアログが出まくります。どっちが悪いというものではない事柄でしょうが，めっさウザイです。
対象フォルダ
・マイドキュメント
10MB
・MyDoc(VSSで管理している文書のワークコピー)
100MB
・鶴亀メールのデータフォルダ
1.5GB
まず，キャッシュなのか，ハッシュなのか，インデクスなのか知りませんが，検索対象フォルダを前処理しなければなりません。前2者は，数分で完了しましたが，鶴亀メールのフォルダは，1時間15分かかりました。
インデクス生成としては，かなり高速だと思います。確かに。検索も対象の分量を考えればマジはえ〜っていうのは分かります。んが，ちょっと困った問題があるのです。それは，インデクス生成中の負荷です。
CPU使用率が100%近くなるのは構わないのです。UDだって，常時100%ですし，Googleデスクトップ検索だってCPU使用率を食います。しかしConceptSearchの致命的な問題は，ユーザインターフェースに影響する点です。
まるでフリーズ状態です。しかもその現象が断続的なので，「お。インデクス生成しながらWebブライジングしようかな」と操作を始めた途端に擬似フリーズ状態になります。まるで，32MBしかメモリを積んでいないWin3.1マシンで1MBくらいのWORDファイルを編集しているかのようです。あるいは，128MBくらいのメモリのマシンでWinXPを使ってスワップ×スワップ状態です。
正直，これは
なんじゃこりゃ
です。ユーザビリティもへったくれもありません。おそらく，1GBのファイルというのは，かなり量が少ない方ですから，実際のオフィスワーカの検索対象ではインデクス生成にもっと時間を要するでしょう。（そりゃマシンが5倍も早けりゃ大丈夫でしょうが）
そもそもインデクス生成作業のスケジュール機能をデフォルトにしている時点で，
他の作業をしながらインデクス生成を定期的におこなう
という使い方を想定しているんでしょう？もし想定していて，この有様ではお金を出すわけにはいかないですね。
CPU使用率をほぼ常時99%ガッチリ掴むUDですら，他のアプリケーションの動作をこれほど邪魔しませんよ。おそらく，メッセージポンプをちゃんと回していないという，猫でもわかるレベルの実装技術なんだと思うのですが，それすらできていないというのはどうなんでしょうか。で，よくあるそういう他のアプリと同様に，「スケジュール処理の優先度」設定を変えても挙動がほとんど変化することなく所要時間は優先度に反比例するという間抜けぶりです。もしかしてこれは，「見切り発車品」ですか？
そのほかにも問題がありました。たとえば，上記の鶴亀メールのフォルダのように，インデクス生成に時間がかかる更新作業を途中で止めると，その後に検索かけたときに，ものすげー時間がかかります。どう見てもフリーズ状態ですが，じっと待っていると検索が完了します。検索動作もCPU使用率と，メッセージポンプの回し方がまずいんじゃないでしょうか。
この手の問題は，Unix系のツールを無理やりGUIアプリから呼び出したりするようなGUIラッパでは当然のように見かけますが，このツールはその程度のものということなんでしょうか。
動作環境
Pentium（R) 133MHz以上/64MByte以上
http://www.justsystem.co.jp/conceptsearch/06.html
これ，まじめに書いてますか？だめだこりゃ。
ここまでコキおろすには，検索結果について非常に大満足だからです。よく言えば一点豪華。悪く言えば，画竜点睛を欠く，企画倒れです。とてもとても，もったいないです。
環境メモ：
WindowsXP pro (Duron1.3G/1GB)
ConceptSearch体験版(1.0.0.1)
ごみためのランキングはこちら。
