私が望んでいるのは、GWTによって行われたDOM操作に支払うパフォーマンスの価格をある程度理解することです。どの操作が「高価」でどれがそうでないか、そしてそれをどのように測定できるかを知りたいです。これらの操作をどのようにプロファイリングできるか知りたいのですが、この問題にまったく注意を払う価値がないかもしれません。
より正確には、これが私が遭遇したユースケースのリストです。
1)ユースケース#1:何らかのイベントが発生した場合に外観を変更するウィジェットがあります。古いウィジェットを削除して新しいウィジェットを作成する場合、または既存のウィジェットのスタイルを変更する方がよい場合、違いはありますか?言い換えれば、GWTアプリで新しいウィジェットを作成して挿入するコストはどれくらいですか?削除されたDOM要素用のガベージコレクターはありますか?
2)ユースケース#2:サーバー側から/サーバー側でデータを取得または保存する必要があります。データは非常に大きくなる可能性があります。非常に単純化された方法でこの操作を行う特別なサーブレットを作成する意味はありますか?標準のGWTサーブレットへのRPC呼び出しを行う代わりに、文字列を受け入れるか出力するだけですか?これはパフォーマンスを上げるための良い方法ですか?自作サーブレットは非常に単純なものにすることができます。
3)ユースケース#3:他のウィジェットの長いリストであるウィジェットがあります。クライアント側のパフォーマンスのために表示するのに安全なウィジェットの数をどのように見積もることができますか?つまり、過去5年間に500万件のチャットメッセージを表示すると、アイテムを部分的にロードしたとしても、クライアント側の速度が低下し、サーバー側のストレスが制限される可能性があります。
4)ユースケース#4:コンテナ内の要素の数を調べたり、要素のスタイルを調べたりするなど、dom操作のパフォーマンス価格はどうですか?たとえば、チャット内のメッセージの数を数える必要があります。チャットコンテナのDOMの子をカウントするこの操作は非常にコストがかかるため、(Javaコレクションと同様に)個別のカウンタを実装し、新しいメッセージが到着したときにそれを増やす方がよいでしょうか。