htmlコントロールにrunat = serverを使用してパフォーマンスノックオン
-
19-09-2019 - |
質問
私はこれをグーグルで検索しようとし、少し短くなりましたので、ここの誰かがこのトピックに光を当てることができます。
ASP.NETのURL書き換えの目的では、Runat = "Server"属性を使用してアプリケーション内のすべての画像およびその他のリソースを宣言して、「〜/Images」サーバーパス構文を活用したいと思います。 Locahostでのデバッグは、相対パスを使用する場合(URL書き換えを使用する場合)特に困難です。この問題を多少克服するためにホストファイルを変更できることは知っていますが、これは私たちが取り組んでいるプロジェクトの量のために実行不可能です。
HTMLコントロールをRunat Serverに宣言することは、通常、ViewStateに追加されてデータの持続性を有効にしますが、これは画像とは関係ありません。
また、ASPネットランタイムエンジンが処理および処理するためのより多くのコントロールがあることも認識していますが、これは本当に深刻なパフォーマンスドレインですか...?
この方法で画像を宣言する際に深刻なオーバーヘッドがありますか?もしそうなら、誰かがパフォーマンスノックの大部分がどこから来るのかを説明できますか。
前もって感謝します。
解決
次の間の違いを求めていると仮定してください。
1) <img runat="server" EnableViewState="false" src="~/images/img.png" />
と
2) <img src='<%= ResolveUrl ("~/images/img.png") %>' />
1)を作成するには、生成された実際のコード(多かれ少なかれ)です。
System.Web.UI.HtmlControls.HtmlImage __ctrl;
__ctrl = new System.Web.UI.HtmlControls.HtmlImage();
this._bctrl_1 = __ctrl;
__ctrl.EnableViewState = false;
__ctrl.Src = "~/image.png";
その後、その__ctrlがコントロールツリーに追加されます。
__parser.AddParsedSubObject(this._bctrl_1); // _bctrl_1 is __ctrl from above
ページライフサイクル(init、load ...)のイベントがこのコントロールに伝播され、レンダコントロールが呼び出され、HTMLを取得します。呼ばれます。
現在、ケース2)では、コントロールはその親に通常の方法で追加されませんが、代わりに次のようなものを取得します。
__ctrl.SetRenderMethodDelegate(new System.Web.UI.RenderMethod(this.__RenderTree));
これは、レンダリングする時間に呼び出される代表者を設定していますu003Cimg>。 __rendertreeでは、私たちが興味を持っているタグを書く部分は次のとおりです。
__output.Write("\n<img src='");
__output.Write( ResolveUrl ("~/image.png") );
__output.Write("' />\n");
したがって、はい、1)で実行されているコードの「多く」があります。さて、実際の実行時間への影響に関しては、これはそれほど大したことではないと思います。 IMGタグ/コントロール以外は何もない空のページをテストしましたが、いくつかの実行での違いは、リクエストあたり-0.5ms/++0.5msの範囲でした。 まったく無視できます.
他のヒント
重要なことがあります 相対的 あなたがすべてのViewState Marlarkyをオフにしたと仮定しても頭上です。しかし 絶対の コストはおそらく個々のユーザーが知覚できないでしょう。
一連のHTML要素を説明するマークアップを考えてみましょう。ページレンダリングの適切なポイントで、コンテンツ全体を非常に効率的に応答に送信する単純な文字通りの「コントロール」として扱われます。
すべてのオブジェクトの作成、スタイル要素の解析、検証など、地方状態の作成により、完全なコントロールとして作成されているすべての同じ要素と比較してください。次に、コードを実行してローカル状態を取得し、そもそもASP.NETページで定義するために使用される同じHTMLマークアップをほとんどレンダリングします。
明らかに、多くのrunat = "server"を使用するメモリとCPUに関しては、より高価になります。個々のケースでは、これはおそらく問題ではありませんが、重要なアクティビティを持つサイトでは、それが可能性があります。
より大きなサイトのいくつかの仮想ディレクトリに配置されるアプリケーションを開発している場合は、画像に相対パスを使用します。
独自のサイトにあるアプリケーションを開発している場合は、プロジェクトまたはサイトのプロパティで、開発者Webサーバーカテゴリの仮想パスを「/」に変更します。そうすれば、デバッグ時にURLに追加 / myProjectName / partがありません。これにより、一部のアセットまたは画像フォルダーへの絶対パスを使用できます。