Prestazioni Knock On Utilizzo di RUNAT = Server per i controlli HTML

Question

Ho provato a Google questo e sono venuto un po 'corto, quindi forse qualcuno qui può far luce sull'argomento.

Ai fini della riscrittura dell'URL in ASP.NET, vorrei dichiarare tutte le immagini e altre risorse nella mia applicazione con l'attributo RUNAT = "Server" per sfruttare la sintassi del percorso del server "~/immagini". Il debug su Locahost è particolarmente difficile quando si utilizzano percorsi relativi (quando si utilizzano la riscrittura dell'URL). So di poter modificare i file host per superare in qualche modo questo problema, ma ciò non è fattibile a causa del volume di progetti su cui lavoriamo.

Dichiarare i controlli HTML a Runat Server si aggiungerà normalmente a ViewState per consentire la persistenza dei dati, ma ciò non sarebbe rilevante per le immagini, o mi sbaglio per quanto riguarda questo ...?

Mi rendo anche conto che ci sono più controlli per il motore di runtime net ASP da elaborare e gestire, ma è davvero uno scarico di prestazioni serio ...?

Esiste un overhead grave nel dichiarare immagini in questo modo, e in tal caso, qualcuno potrebbe spiegare da dove verrà esattamente la maggior parte del bussare alle prestazioni.

Grazie in anticipo.

Answer 1

Supponendo che tu stia chiedendo le differenze tra:

1) <img runat="server" EnableViewState="false" src="~/images/img.png" />

e

2) <img src='<%= ResolveUrl ("~/images/img.png") %>' />

Per costruire 1), il codice effettivo generato (più o meno) è:

System.Web.UI.HtmlControls.HtmlImage __ctrl;
__ctrl = new System.Web.UI.HtmlControls.HtmlImage();
this._bctrl_1 = __ctrl;
__ctrl.EnableViewState = false;
__ctrl.Src = "~/image.png";

Quindi quel __ctrl viene aggiunto all'albero di controllo:

__parser.AddParsedSubObject(this._bctrl_1); // _bctrl_1 is __ctrl from above

Qualsiasi evento nel ciclo di vita della pagina (init, caricamento ...) verrà propagato a questo controllo, il rendercontrol sarà chiamato per ottenere l'HTML da esso, Resolveurl () viene chiamato per ottenere l'URL effettivo e, infine, disposoni () sarà chiamato anche.

Ora, nel caso 2), il controllo non viene aggiunto al suo genitore nel modo normale, ma invece ottieni qualcosa del genere:

__ctrl.SetRenderMethodDelegate(new System.Web.UI.RenderMethod(this.__RenderTree));

Che sta impostando un delegato che verrà chiamato quando è il momento di rendere ilu003Cimg> . In __rendertree la parte che scrive il tag che ci interessa è:

__output.Write("\n<img src='");
__output.Write( ResolveUrl ("~/image.png") );
__output.Write("' />\n");

Quindi, sì, c'è "molto" di codice eseguito in 1) che non viene eseguito in 2). Ora, per quanto riguarda l'impatto nel tempo di esecuzione reale, penso che questo non sia un grosso problema. Ho testato una pagina vuota con nient'altro che il tag/controllo IMG e la differenza tra loro in diverse corse era nell'intervallo di -0,5 ms/+0,5 ms per richiesta. Totalmente trascurabile.

Answer 2

C'è un significativo parente Overhead supponendo che tu abbia spento tutti i ViewState Marlarky. In ogni caso, il assoluto Il costo è probabilmente inoperibile a un singolo utente.

Considera un markup che descrive una serie di elementi HTML, è trattato come un semplice "controllo" letterale che invia in modo molto efficiente il suo contenuto alla risposta nel punto appropriato nel rendering della pagina.

Confrontalo con tutti gli stessi elementi creati come controlli completi con tutta la creazione di oggetti, l'analisi dell'elemento di stile, la convalida ecc. E la creazione dello stato locale. Quindi il codice viene eseguito per prendere lo stato locale e praticamente renderlo lo stesso markup HTML utilizzato per definirlo nella pagina ASP.NET in primo luogo.

Chiaramente in termini di memoria e CPU usando molti runAt = "server" è più costoso. In un singolo caso questo non è probabilmente un problema, ma per un sito con attività significativa potrebbe essere.

Se si sta sviluppando un'applicazione che verrà inserita in una directory virtuale in un sito più grande, usa i percorsi relativi per le tue immagini.

Se si sta sviluppando un'applicazione che si trova a un sito a sé stante, nel progetto o nel sito Proprietà modifica il percorso virtuale nella categoria Server Web sviluppatore in modo che sia solo "/". In questo modo durante il debug non si dispone di extra / myprojectname / parte nell'URL. Ciò ti consentirà di utilizzare un percorso assoluto per alcune risorse o immagini di immagini.