7
votes

Comportement de performance étrange

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);
        }
    }
}


1 commentaires

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.


3 Réponses :


15
votes

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 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.

(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.)

(et comme Mitch, je peux confirmer que je vois le même effet.)

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 haystack.indexof (aiguille, stringcomparison.ordininignorecase) : < / p>

  • sur .NET 2, les résultats sont à peu près la même chose si grosse "l'aiguille" est
  • sur .NET 4:
    • Si aiguille est plus grand que HAYSTACK (selon votre exemple) .NET 4 est beaucoup plus rapide que .NET 2
    • Si aiguille est la même taille que HAYSTACK , .NET 4 est un peu peu plus lent que .NET 2
    • Si aiguille est plus petit que HAYSTACK , .NET 4 est un lot plus lent que .NET 2

      (Ceci est en train de garder un test lorsque le premier caractère de aiguille n'apparaît jamais dans HAYSTACK , BTW.)


3 commentaires

Ne devrait pas "quand vous le forcer à utiliser .NET" Lire "lorsque vous le forcez à utiliser .NET 4 "?


«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.



4
votes

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.

donc probablement indexof () a été optimisé dans .NET 4.0


0 commentaires

3
votes

OK, quelques points de repère avec le nouveau VS11

.NET 4.0 : 12100 ms
.NET 2.0 :  1700 ms


5 commentaires

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.