Quelle est la quantité de calculs derrière un appel HttpContext.Current?

Question

Est-ce cher?

Je développe une HtmlHelper qui rend directement à Response.Output pour sauver la création de chaînes unnecesary et je dois choisir entre:

<% Validator.RenderClient(Response.Output); %> 

et

<% Validator.RenderClient(); %> 

et obtenir le TextWriter de HttpContext.Current.Response

Answer 1

@Dawkins

100 __gVirt_NP_NNS_NNPS<__ pistes, vous devez exécuter environ 10 000 fois à plusieurs reprises et de le répéter, puis prendre la moyenne de ce pour obtenir un résultat fiable. La marge d'erreur est grande dans votre exemple, mais c'est la bonne façon de procéder.

Voici ce que je l'ai fait:

var results1 = new List<long>(); 
var results2 = new List<long>(); 

for (int j = 0; j < 100; j++) 
{ 
    var sp = new System.Diagnostics.Stopwatch(); 

    // With HttpContext.Current: 
    sp.Start(); 
    for (int i = 0; i < 10000; i++) 
    { 
     HttpContext.Current.Response.Output.Write(i); 
    } 
    sp.Stop(); 

    results1.Add(sp.ElapsedTicks); 

    // Without: 
    TextWriter output2 = HttpContext.Current.Response.Output; 
    sp.Reset(); 

    sp.Start(); 
    for (int i = 0; i < 10000; i++) 
    { 
     output2.Write(i); 
    } 
    sp.Stop(); 

    HttpContext.Current.Response.Clear(); 

    results2.Add(sp.ElapsedTicks); 
} 

results1.Sort(); 
results2.Sort(); 

HttpContext.Current.Response.Write(string.Format("HttpContext.Current={0:0.000}ms, Local variable={1:0.000}ms, R={2:0.0%}<br/>", results1[results1.Count/2]/(double)TimeSpan.TicksPerMillisecond, results2[results2.Count/2]/(double)TimeSpan.TicksPerMillisecond, (double)results1[results1.Count/2]/(double)results2[results2.Count/2])); 

Votre résultat montre qu'il ya une différence de performance de 18%, ce qui montre qu'il est plus cher mais hors de 8%.

J'ai réexécuté les nombres plusieurs fois et ai obtenu une différence de 10% avec une marge d'erreur inférieure à 1%.

Il stablaizes autour de:

HttpContext.Current=0,536ms, Local variable=0,486ms, R=110,2% 

Quoi qu'il en soit, HttpContext.Current poser un problème de performance importante que vous aurez besoin de l'appeler ainsi plus de 10 000 par demande (le coût est largement compensé par la réponse. Écrire des appels). Et cela ne va probablement pas arriver.

Answer 2

à partir du réflecteur

public static HttpContext get_Current() 
{ 
    return (ContextBase.Current as HttpContext); 
} 

appels ContextBase qui appelle

public static object HostContext 
{ 
    get 
    { 
     object hostContext = 
      Thread.CurrentThread.GetIllogicalCallContext().HostContext; 
     if (hostContext == null) 
     { 
      hostContext = GetLogicalCallContext().HostContext; 
     } 
     return hostContext; 
    } 

...

donc il y a un peu de filetage 'choses' en cours; le spécifique je ne sais pas vraiment.

Answer 3

Ce n'est pas intensif du tout. Je ne sais pas pourquoi je ne l'ai pas essayé ce la première fois:

 System.Diagnostics.Stopwatch sp = new System.Diagnostics.Stopwatch(); 

     // With HttpContext.Current: 
     sp.Start(); 
     for (int i = 0; i < 100; i++) 
     { 
      HttpContext.Current.Response.Output.Write(i.ToString()); 
     } 
     sp.Stop(); 
     long result1 = sp.ElapsedTicks; 

     // Without: 
     TextWriter output2 = HttpContext.Current.Response.Output; 
     sp.Reset(); 
     sp.Start(); 
     for (int i = 0; i < 100; i++) 
     { 
      output2.Write(i.ToString()); 
     } 
     sp.Stop(); 
     long result2 = sp.ElapsedTicks; 

Et mes résultats informatiques sont autour de:

result1 = 395 tiques result2 = 332 tiques

Il est assez vite! est trop peu