読者です 読者をやめる 読者になる 読者になる

「日本語 IME 開発現場における Engineering Excellence」

2007年4月16日に開催された MSDN オフラインセミナー「日本語 IME 開発現場における Engineering Excellence」の内容が Web キャストで公開されているようなので,ざっと一通り見てみました.

感想としては,自身の経験から見ても頷ける内容が多く,言うならば「毒気のない Joel on Software」でした.これならお子様に見せても安心と.
特にパフォーマンスに関して取り組みかなり全面的に肯定できる内容でした.それなのに……それなのになんで MSIME 2007 はあんなにパフォーマンス問題が各地で大発生,という状態で出荷されてしまったのか.多くのユーザはそこを聞きたいんじゃないかと思います.それとも,実はこの取り組みを行ったのが Vista 標準の MSIME で,行わなかったのが MSIME 2007 というオチだったりするんでしょうか?
まあありそうなのは,開発中はもっと重かったというパターンですかね.私も Vista ベータ時代の重さを知った上で,RC 後期のパフォーマンスの改善具合を見て「おお,これは軽い」と喜んだ口なので,改善していることによって前向きに評価したくなるのは分かります.あるいは,開発途中から長いこと使っていると,どういうことを行うと重くなるかがだんだんわかってくるので,無意識にそういうのを避けたり,予め身構えたりして,「重さ」へのバイアスはだんだん低くなってくるのかもしれません.
こういう事態を避けるために,きちんと数値目標を立てておいた方が良いのでしょうね.講演では,「プログラマの思いこみは案外当てにならないからちゃんとプロファイラで測定する」という,あたりまえでも中々難しいことがちゃんと述べられていましたが,GUI アプリケーションで重要なのはスループットではなくレスポンスタイムの安定性で,これは結構測定しにくかったりします.例えばキー入力に応答するまでの時間を毎回測定しておいて,それの最大値が目標値を上回らない,といったアプローチが必要になるでしょう.
レスポンスを悪化させる要因には,同期 I/O やプロセス間通信のブロッキング,ハードページフォルト,単なる重い計算など様々なものが考えられますが,原因は何にせよ重要なのは最悪時のレスポンスです.MSIME 2007 に,応答時間を計測するプロファイルモードがあって,それを使うことでボトルネックが改善するのであれば,いくらでも協力するのですが,もしそういうモードが無いのであれば次回までに用意しておいてもらえるとよいですね.

参考