JとNの狭間
やっと落ち着いて.NETの仕事を再開できると思ったのだが、またJavaの仕事に逆戻り。両方やってみて思うのは、やはりサーバサイド(Java)とクライアントサイド(.NET)では、設計方針が全く異なること。(このサイド分類は、たまたま私の担当するシステムがそうなっているだけで、他意はない。)
- サーバサイドアプリケーション
オブジェクトは長くヒープ上に留まっていても良い
インスタンス数はできるだけコントロールしたい
ロードに時間がかかっても気にしない(初回だけ遅いなら良し)
できるだけ再起動したくない、再起動せずに状態を変えたい
- クライアントサイドアプリケーション
あまり大量のオブジェクトをヒープに積みたくない
起動時のロード時間はできるだけ短くしたい(見かけ上だけでも)
再起動されるのは当たり前。
クライアントサイドはすぐに人目につくのでやっかいだ。ロード時間とメモリの見かけ上の消費量はあまりシステムに詳しくないユーザも真っ先に突っ込める部分だから。
一度でもシステム構築を経験したユーザは、タスクマネジャでプロセスがどれ位メモリをホグしているのかを確認する位のことはする、と考えるべきだが、.NETの場合、実際に消費しているメモリでなく、予約されているメモリ(WorkingSet)が見えているため、お願いだからタスクマネジャだけで判断してくれるな、と言い訳したい気持ちになる。
.NETのクライアントに関しては以前から、そのワーキングセットがかなり大きく取られているのが気になっていたので、拙作のスマートクライアント用のフレームワークでは、ページフォルト覚悟でワーキングセットを動的に(ディアクティベイトされた時やアイドル時に)縮小する仕組みを組み込んであるのだが、以前にNyaRuRuさんの日記で言及されていたあたり
を読むと、単純にワーキングセットを縮小するのも良くないな、と思うので悩ましい所だ。
某ビデオチップベンダのユニバーサルドライバで使用している設定用のアプレットは、.NET Frameworkで開発、提供されているのだが、その重さを少しでも目立たなくする工夫と思われる機構が、ドライバと共にインストールされる。このような「工夫」にはサーバサイドアプリケーションの考え方が適用されるのが面白いところだ。
.NETもJavaもだが、クライアントサイドは速さも効率も「見かけ上」が大切であり、その為にはクライアントとはいえども、サーバサイドアプリケーションの考え方が取り込まれることもあり得る。というか、仮想技術を採り入れたプラットホームは、それ自体がサーバみたいものか。
