検索中もユーザへのフィードバックを続けるために、検索部分をきちんとスレッド化することにした。Mac OS上でのMulti Thread Programmingに関しては、ここが詳しい。基本的にはPOSIXスレッドかそれをカプセル化したNSThreadクラスを使うことになる。
検索用のスレッドは次の検索タームが入力された時点で、処理をストップして、次の検索をはじめる必要がある。このための処理に関しては次のスレッドが役に立った。
Pausing and terminating a thread
より詳しくはこちら。
Thread Cancellation And Termination

6000種ともいわれる世界の言語を話者数の多い順にソートしてみると，上位4%の言語を世界人口の96%の人々が話している，という内容の文章で始まる8月25日付けの仏ル・モンド紙の危機言語に関する記事．

La mondialisation menace la planete Babel

遠藤拓己

Mac OS X TigerのCoreDataの話。データモデリングで作った複数のEntityをInterfaceBuilder、NibファイルのWindow上にドラッグすると、各Entityごとに適当なGUI (ソート機能付きのTableView, サーチウィンドウなど）が自動で生成される。同時に、TableViewにデータを供給するためのNSArrayControllerもbindingされた状態で、適宜自動で生成される。ここで注意したいのは、同じEntityの集合を表すNSArrayControllerが複数できる可能性があることだ。
あとえば、下のデータのような場合、WordとLanguageのためのTableをつくると、相互にRealationshipがあるために、wordとlanguageのEntityをcontentsとしてもつNSArrayControllerが複数できる。

二重、三重にNSArrayControllerのcontensが更新されるのは無駄が多い。一つのNSArrayControllerをTableViewから参照するようにすると、効率がよい。

当初はSQLite自体のQUERYの速度がボトルネックになっているのかと思っていたが、SQLite自体はMySQLやPostgreSQLよりも圧倒的に速いらしい。Sams 社の本、”SQLite“にもそう明記されている。

ただし、サーバ／クライアントシステムを想定していないため、Lockの機能が粗く、マルチスレッドのアプリケーションなどで複数のプロセスが同時に読み書きするような場合は、他のDBに分がある。少なくとも、今回のわれわれのプロジェクトの場合、速度に限って言えばSQLiteを使うことに問題はなさそうだ。
では、なぜこんなに検索が遅いのか….

トランジットでパリ・CDG空港に立ち寄った未踏ソフトウェアの北野宏明PM(SONY CSL)と、プロジェクトの進捗報告と今後の開発の方向性についてのディスカッションを行った。以下の写真が現在製作中のプロトタイプのスクリーンショットである。中央の単語に似た発音を持つ単語が表示されている。

現在の大きな問題点としては、以下の二つがあげられる。

1. 電子的な辞書データの絶対的不足
発音記号が付加された辞書をみつけるのが、当初予想されたよりも難しいことがわかった。特に、英語、フランス語、ドイツ語などのメジャー言語(強い経済力を持つ国の言語と言うべきか)以外になるとデータそのものが存在しない場合が頻繁にみられる。
こうした言語に対する対応が最大の課題である. 対処法として、
* 研究者のコミュニティーに協力をもとめる
* wikipediaのようなコミュニティーベースのオンライン投稿システムを実装する。
* 単語のスペルから発音を推定するアルゴリズムを実装する。
などが考えられる。最後のアルゴリズムに関しては、一定量のスペル、発音のペアのサンプルを用いてニューラルネットによる学習が有力か。
(辞書の問題は、遠藤の方からもこの後説明があるはず。)

2. DBアクセスの高速化
現在、辞書データはsqliteのデータとして格納され、検索語が入力されるたびに検索語とのPhonethicaな距離を計算に上位数パーセントを表示するようにしている。DBのエントリーを一通りスキャンする必要があるため、検索語を検索してから結果が帰ってくるまで、10sec以上かかっており、実用的ではない。　
まず、sqliteのクエリー自体に非常に時間がかかっている。単純なselect文なのだが、答えが返ってくるまでに数秒かかっている。データのエントリー数は30万強。そもそも小規模なPC用のsqliteをこの規模のデータに使うのは無理があるのか。それともMac OS X、CoreDataのパフォーマンスの問題なのか。
また検索語が入力されるたびに距離を計算するのはどうかんがえても効率的ではない。あらかじめ距離を一通り計算して結果のみを保持するような形が好ましいが、その場合、すべてのエントリーに対して距離を計算するための計算パワーが必要になる。計算パワーの確保も大きな課題か。