TOKUNAGA Hiroyuki
tkng****@xem*****
2005年 3月 2日 (水) 21:36:07 JST
徳永です。ただいまCodefest Asiaの会場に来ています。右斜めの方に半田さ んが見えます。 On Mon, 28 Feb 2005 14:57:46 +0900 (JST) Kenichi Handa <handa****@m17n*****> wrote: > >> 以上の変更で latn-post/pre が起動できるようになります。ただ、 > >> 動作がどうもおかしく、たとえば "a'" と打つと a-grave が > >> preedit として表示されますが、続いて "f" とうつと a-grave は > >> commit されますが、 "f" が無視されるようです。これはまだ原因 > >> がわかりません。 > > > m17nlib.scmのm17nlib-press-key-handlerが非常に怪しいです。しかし、 > > そろそろ0.4.6をリリースしたいので、とりあえず後回しにします。 > > このように0.4シリーズにはまだだいぶ積み残しがあるので、0.6.0までの > > つなぎとして、0.4.6以降もリリースしようかと考え始めました。 さっき半田さんに原因を調べていただいたのですが、minput_lookupの返り値 を捨てているのが原因でした。 原因がわかったので修正は可能なのですが、libuimのコードに手を入れないと 修正は不可能っぽいです。予想以上にめんどくさいバグなので、いつ治せるかわ からないです。 # Codefestの期間中に修正できたら快挙 > >> (5) ic_array[id].old/new_candidates があるんですが、 > >> ic-> candidat_list の plist をそのまま毎回使った方が速いと思 > >> うのですが。 > > > ベンチマークを取った訳ではないですが、例えば50個の候補があったとし > > て、 41〜50個目の候補を取得しようと思った場合、候補のキャッシュをし > > ないと mplist_nextが (41 + 50)/2*10回で450回ほど呼ばれる事になるの > > で、キャッシュした方が早いように思えます。（キャッシュ領域を確保する > > のに最初に50回 malloc呼ぶ方が重いかも知れませんけど…。） > > ic->candidate_list は実際は候補グループのリストなので、例えば > 各候補が１０個づつのグループになっていて、各グループが plist > で表現されている場合でも、40+N (N=1..10) 個目の候補の取得には > mplist_length * 5 + mplist_next * (4 + N - 1) 回の関数呼び出 > しですむはずなので、計 mplist_length * 50 + mplist_next * 49 > 回の関数呼び出しになるはずです。各グループが M-text の場合 > （中国語の入力メソッドは殆どがこれですが）はもっと早くなりま > す。 > > それに、実際に候補を取得しようとするのはユーザのアクションに > 対応しての処理になるはずなので、ここの処理は相当遅くなっても > 問題ないと思うのですが。 zh-pyだとキータイプ毎に候補が更新されるようです。候補ウィンドウを作る負 荷を考えれば焼け石に水かなという気もしますが、速いに越したことはなさそう です。 あと、前回メールしたときには忘れてたのですが、速度的な問題だけでなく、不 要な候補のアップデート処理を行わないようにするためにold/new_candidatesが 必要です。 -- 徳永拓之 tkng****@xem***** http://kodou.net/
