J'utilise Visual Studio 2010 SP1, Cadre cible est 2.0, Target de la plate-forme: tout CPU, test sous Windows 7 x64 SP1.
Je connais un comportement de performance étrange. P>
sans app.config, ou avec l'app.config suivant, il fait fonctionner mon programme lentement (SHOPWatch Affiche ~ 0,11 s) P>
using System;
using System.Collections.Generic;
using System.Text;
using System.Diagnostics;
class Program
{
static void Main(string[] args)
{
Stopwatch sw = new Stopwatch();
while (true)
{
sw.Reset();
sw.Start();
for (int i = 0; i < 1000000; i++ )
{
"blablabla".IndexOf("ngrhotbegmhroes", StringComparison.OrdinalIgnoreCase);
}
Console.WriteLine(sw.Elapsed);
}
}
}
3 Réponses :
On dirait que vous venez de trouver une situation dans laquelle .NET 4 est beaucoup plus rapide. Par défaut, votre application s'exécute avec le cadre qu'il a été conçu pour cibler. Lorsque vous force em> utiliser .NET 4, il est plus rapide. Cela peut être une amélioration du compilateur JIT qui frappe votre situation ou une amélioration-cadre peut être une amélioration-cadre - mais elle ne devrait pas être trop surprenante que certaines choses sont plus rapides dans les versions plus récentes. P>
(Pour ce que ça vaut, j'augmenterais le nombre d'itérations que vous positionnez si j'étais vous ... sur ma boîte sous .NET 4, chaque itération n'est que 10 ms, ce qui n'est pas vraiment un excellent mesure. Je préfère une référence pendant au moins quelques secondes.) p>
(et comme Mitch, je peux confirmer que je vois le même effet.) p>
Edit: Je viens d'enquêter sur cela un peu plus loin, et j'ai vu un effet intéressant ... je suppose que nous appelons (Ceci est en train de garder un test lorsque le premier caractère de haystack.indexof (aiguille, stringcomparison.ordininignorecase) code>: < / p>
aiguille code> est plus grand que HAYSTACK code> (selon votre exemple) .NET 4 est beaucoup plus rapide que .NET 2 LI>
aiguille code> est la même taille que HAYSTACK code>, .NET 4 est un peu em> peu plus lent que .NET 2 LI>
aiguille code> est plus petit que HAYSTACK code>, .NET 4 est un lot em> plus lent que .NET 2 LI>
ul> li>
ul>
aiguille code> n'apparaît jamais dans HAYSTACK code>, BTW.) P>
Ne devrait pas "quand vous le forcer à utiliser .NET" Lire "lorsque vous le forcez à utiliser .NET 4 B>"?
«Si l'aiguille est plus petite que le brakstack, .NET 4 est beaucoup plus lent" - semble une très mauvaise optimisation alors.
@HENKHOLTERMAN: En effet. Je devais me précipiter après avoir testé cela - si vous (ou quelqu'un d'autre) pouvait le reproduire, ce serait utile.
Je viens de courir votre référence avec quelques modifications (qui incluaient plus d'itérations et de plus en moyenne), et peuvent confirmer que la version ciblée .NET 4.0 est en effet 4-5 fois plus rapide. P>
donc probablement indexof () code> a été optimisé dans .NET 4.0 P>
OK, quelques points de repère avec le nouveau VS11
.NET 4.0 : 12100 ms .NET 2.0 : 1700 ms
WOW - C'est vraiment étrange - merveille si certains internes au CLR / BCL pourraient dire quelque chose à ce sujet ...
Qu'est-ce que même le point de chercher une longue aiguille dans une courte foin? N'est-ce pas faux par conception?
@ YAS4891: Oui, mais c'était la question initiale et il a une performance très différente.
FWIW, .NET 4.5 n'est pas côte à côte, il écrase .NET 4.0. Même chose avec .NET 3.5 VS 2.0. C'est pourquoi les horaires sont les mêmes. Attention avec 4,5, avec elle dans la pré-libération et le whacking 4.0 Vous ne pouvez pas tirer de véritables conclusions.
@Hans, OK, je savais seulement environ 3,5 / 2.0. Devrait être lu sur 4,5.
La classe System.string lui-même a été modifiée dans .NET 4. Avec beaucoup de travail sur les bits NLS dans le CLR. Vous ne pouvez pas raisonnablement vous attendre à des résultats similaires, seul espoir.