ComNifty内部処理時間の推測
[ Back | Home | ASAHIネット会員Home Page一覧 | ASAHIネットHome Page ]
ComNiftyを高速化するパッチ前後の受信性能を測定した下記のデータから，ComNiftyの内部処理の状況を大まかに推測してみました。この推測は，私のPB2400c/400の測定結果からのもので，マシンが違えば状況も違います。
この推測では，まずComNiftyの内部処理を下記に分類して考えます。厳密には，これほど単純でないと思いますが，大まかにはこの様な傾向があると思われます。
- データ依存処理
受信するデータに対して一定の比率で行われる処理です。具体的には，シリアルドライバの処理やComNiftyの受信データ処理の基本的な部分です。表示処理の内，ウインドウ最下行の表示処理などもここに含むと考えられます（ウインドウ行数が１行でも25行でも最下行の表示処理は同様に行われるという仮定）。
- ウインドウ行数依存処理
ウインドウの行数によって処理量（負荷）が変化する部分です。具体的には，主にスクロール処理が該当すると思われます。この推測では，ウインドウ行数依存処理の量は，スクロールの対象となる行数（ウインドウ行数−１）に比例するものと仮定しています。
- 遊び時間
イベントループを１回実行する毎に休む時間です。ComNiftyのCPU利用率を上げて速度を向上させるパッチは，この時間をほぼゼロにすると考えられます。
上記の様な処理内容に分解できるという仮定で，パッチ前後で色々なウインドウ行数で受信性能を測定した結果から各処理の処理時間を概算したのが下記のグラフです。このグラフでは，6行表示（ノーマルのComNiftyでSucha 9pのときの最小行数）の場合を示しています。
処理時間を「2KB受信当たり」としたのは，ComNiftyが１回のイベントループの実行で処理できる最大のデータ量が2KB（2048バイト）のためです。ComNiftyは，負荷が大きくComNiftyの性能が限界に達している場合には，１回のイベントループの実行で2KBのデータを処理します。
ただし，パッチで改造したComNiftyでB/W（モノクロ表示）の場合には，23000バイト／秒の転送速度（シリアルポートの限界）であり，ComNiftyの性能に余裕があります。「余裕」というのがこの余裕分を示します。実際には，この余裕がある場合にはイベントループ１回当たりの処理量が2KBより小さくなり，その結果処理効率が低下するため「データ依存処理」＋「行数依存処理」がグラフよりも大きくなって，「余裕」で示した部分までを占めていはずです。
下記のグラフは，上のグラフを処理種別毎の比率を示す様にしたものです。
以上の推測の結果から，下記の様なことが言えます。
- ノーマルのComNiftyは，遊び時間が大きい（私のPB2400c/400ではイベントループ１回当たり260ms前後と推定される）ため，比較的速いマシンでもさほど性能が出ない。遊び時間は，ComNiftyの指定に従いMacOSが管理しています（同時に実行する他のアプリの動作状況も影響すると思われます。ComNiftyのみ実行している場合でも，ファインダー，最近のMacOSのコントロールバーやアプリケーションメニューをタイル表示したり，フォルダアクション機能拡張を有効としたときに動いている見えないアプリの動作状況などが間接的に関係するかも知れません）。もし遊び時間が，マシンの性能（CPU，メモリ，表示性能など）に関係なく一定なら，マシンの性能を上げてもノーマルComNiftyの性能向上率は小さいことになります。
- PB2400cの様に表示が遅い（最新のPowerBookの数分の１の表示性能かな？）機種では，ウインドウ行数に依存した処理の比率が大きく，ウインドウ行数を多くした場合の性能低下が激しい。また，表示色が多いほど，ウインドウ行数に依存した処理に加えてデータ依存処理に分類した処理も増える。しかし，ノーマルComNiftyでは遊び時間の比率がかなり大きいため，表示関係の負荷を大幅に下げたり表示性能の高いマシンにしても効果は割り合い少ない。
- CPU利用率を上げるパッチを当てると，大半を占める遊び時間がほとんどなくなるためComNiftyの性能が大幅に向上する。また，CPU利用率を上げるパッチを当てた状態では，マシンの性能を上げたときや表示行数を削減するパッチを当てたときの効果が，ComNiftyの性能にダイレクトに反映される。
[ Back | Home | ASAHIネット会員Home Page一覧 | ASAHIネットHome Page ]
