2012-03-16 19 views
16

Duplicar posible:
String comparison in dotnet framework 4Rendimiento de String.indexOf OrdinalIgnoreCase vs CurrentCultureIgnoreCase

me di cuenta de un problema de rendimiento en mi máquina en una aplicación de interfaz de usuario que está haciendo un montón de comparaciones de cadenas que hacer filtrado de grandes listas. Seguí el problema hasta usar OrdinalIgnoreCase en una llamada a string.IndexOf. Los siguientes puntos de referencia se ejecutaron en Release sin el depurador adjunto, es un proyecto 4.0 creado en VS 2010, Windows 7, tengo la versión 4.5 beta instalada en esta máquina, no estoy seguro de si eso afectaría esto.

1.190 seconds for OrdinalIgnoreCase 
0.178 seconds for CurrentCultureIgnoreCase 
0.175 seconds for InvariantCultureIgnoreCase 

0.101 seconds for Ordinal 
0.132 seconds for CurrentCulture 
0.126 seconds for InvariantCulture 

1.176 seconds for OrdinalIgnoreCase 
0.189 seconds for CurrentCultureIgnoreCase 
0.183 seconds for InvariantCultureIgnoreCase 

0.104 seconds for Ordinal 
0.138 seconds for CurrentCulture 
0.127 seconds for InvariantCulture 

Como puede ver, OrdinalIgnoreCase es más de 6.5 veces más lento. Pero sin IgnoreCase, Ordinal es el más rápido. En multiple places microsoft recommends OrdinalIgnoreCase para el mejor rendimiento. ¿Alguien puede replicar estos resultados o explicar por qué OrdinalIgnoreCase va mucho más lento en esta prueba?

private static void Test(string search, string key, StringComparison comparison, int trials) 
{ 
    var sw = Stopwatch.StartNew(); 

    for (int i = 0; i < trials; i++) 
    { 
     search.IndexOf(key, comparison); 
    } 

    Console.WriteLine("{0:0.000} seconds for {1}", sw.ElapsedMilliseconds/1000.0, comparison); 
} 


static void Main(string[] args) 
{ 
    int trials = 1000000; 
    var search = Guid.NewGuid().ToString("N"); 
    var key = "34"; 

    Test(search, key, StringComparison.OrdinalIgnoreCase, trials); 
    Test(search, key, StringComparison.CurrentCultureIgnoreCase, trials); 
    Test(search, key, StringComparison.InvariantCultureIgnoreCase, trials); 
    Test(search, key, StringComparison.Ordinal, trials); 
    Test(search, key, StringComparison.CurrentCulture, trials); 
    Test(search, key, StringComparison.InvariantCulture, trials); 

    Test(search, key, StringComparison.OrdinalIgnoreCase, trials); 
    Test(search, key, StringComparison.CurrentCultureIgnoreCase, trials); 
    Test(search, key, StringComparison.InvariantCultureIgnoreCase, trials); 
    Test(search, key, StringComparison.Ordinal, trials); 
    Test(search, key, StringComparison.CurrentCulture, trials); 
    Test(search, key, StringComparison.InvariantCulture, trials); 
} 
+1

no tengo ni idea, pero ¿ha tratado la aleatorización de la orden de prueba para asegurarse de que algo no está causando el retraso en su accesorio de prueba? –

+0

Ok, acabo de probar eso. No es el problema. –

+0

Usando .NET 3.5, los puntos de referencia son relativamente consistentes. Dirigido a 4.0, veo lo mismo que arriba. –

Respuesta

8

Esto es al parecer un problema de rendimiento conocido en .NET 4, encontré this bug entry on connect.microsoft.com

y hay una respuesta

publicado por Microsoft el 2/10/2012 a las 11:43 AM: hemos podido reproducir el problema . El problema se ha resuelto y la solución estará en el próximo lanzamiento de . Gracias por tu retroalimentación.

No estoy seguro de lo que el próximo lanzamiento será, voy a preferir el uso InvariantCultureIgnoreCase lugar

+2

El próximo lanzamiento será .Net 4.5, que saldrá con VS 11. Pero no tengo idea de cuándo será eso o si solucionará este error. – svick