c# - ¿Por qué String.IsNullOrEmpty es más rápido que String.Length?

.net performance

Question

ILSpy muestra que String.IsNullOrEmpty se implementa en términos de String.Length . Pero entonces, ¿por qué String.IsNullOrEmpty(s) más rápido que s.Length == 0 ?

Por ejemplo, es un 5% más rápido en este punto de referencia:

var stopwatches = Enumerable.Range(0, 4).Select(_ => new Stopwatch()).ToArray();
var strings = "A,B,,C,DE,F,,G,H,,,,I,J,,K,L,MN,OP,Q,R,STU,V,W,X,Y,Z,".Split('','');
var testers = new Func<string, bool>[] { s => s == String.Empty, s => s.Length == 0, s => String.IsNullOrEmpty(s), s => s == "" };
int count = 0;
for (int i = 0; i < 10000; ++i) {
    stopwatches[i % 4].Start();
    for (int j = 0; j < 1000; ++j)
        count += strings.Count(testers[i % 4]);
    stopwatches[i % 4].Stop();
}

(Otros puntos de referencia muestran resultados similares. Esto minimizó el efecto de la ejecución de cruft en mi computadora. Además, aparte de eso, las pruebas en comparación con cadenas vacías resultaron ser aproximadamente un 13% más lentas que IsNullOrEmpty ).

Además, ¿por qué IsNullOrEmpty solo es más rápido en x86, mientras que en x64 String.Length es aproximadamente un 9% más rápido?

Actualización: detalles de la configuración de prueba: .NET 4.0 ejecutándose en Windows 7 de 64 bits, procesador Intel Core i5, proyecto de consola compilado con "Optimización de código" habilitado. Sin embargo, también se habilitó "Suprimir la optimización de JIT en la carga del módulo" (ver respuesta aceptada y comentarios).

Con la optimización completamente habilitada, la Length es aproximadamente un 14% más rápida que IsNullOrEmpty con el delegado y otros gastos generales eliminados, como en esta prueba:

var strings = "A,B,,C,DE,F,,G,H,,,,I,J,,K,L,MN,OP,Q,R,,STU,V,,W,,X,,,Y,,Z,".Split('','');
int count = 0;
for (uint i = 0; i < 100000000; ++i)
    count += strings[i % 32].Length == 0 ? 1 : 0; // Replace Length test with String.IsNullOrEmpty

Answer 1

Creo que es imposible que IsNullOrEmpty sea ​​más rápido porque, como el resto dice, también hace una comprobación de nulo. Pero más rápido o no, la diferencia va a ser tan pequeña, que esto le da una ventaja al usar IsNullOrEmpty solo por esta comprobación nula adicional que hace que su código sea más seguro.

Answer 2

Creo que tu prueba no es correcta:

Esta prueba muestra que string.IsNullOrEmpty siempre es más lento que s.Length==0 porque realiza una comprobación nula adicional:

var strings = "A,B,,C,DE,F,,G,H,,,,I,J,,K,L,MN,OP,Q,R,STU,V,W,X,Y,Z,".Split('','');
var testers = new Func<string, bool>[] { 
    s => s == String.Empty, 
    s => s.Length == 0, 
    s => String.IsNullOrEmpty(s), 
    s => s == "" ,
};
int n = testers.Length;
var stopwatches = Enumerable.Range(0, testers.Length).Select(_ => new Stopwatch()).ToArray();
int count = 0;
for(int i = 0; i < n; ++i) { // iterate testers one by one
    Stopwatch sw = stopwatches[i];
    var tester = testers[i];
    sw.Start();
    for(int j = 0; j < 10000000; ++j) // increase this count for better precision
        count += strings.Count(tester);
    sw.Stop();
}
for(int i = 0; i < testers.Length; i++)
    Console.WriteLine(stopwatches[i].ElapsedMilliseconds);

Resultados:

6573
5328
5488
6419

Puede usar s.Length==0 cuando esté seguro de que los datos de destino no contienen cadenas nulas. En otros casos, te sugiero que uses el String.IsNullOrEmpty .

Answer 3

En CLR a través de CSharp capítulo 10 "Propiedades" Jeff Richter escribe:

Un método de propiedad puede tardar mucho tiempo en ejecutarse; El acceso al campo siempre se completa de inmediato. Una razón común para usar las propiedades es realizar la sincronización de subprocesos, que puede detener el subproceso para siempre, y por lo tanto, no se debe usar una propiedad si se requiere la sincronización de subprocesos. En esa situación, se prefiere un método. Además, si se puede acceder a su clase de forma remota (por ejemplo, su clase se deriva de System.MarshalByRefObject ), llamar al método de propiedad será muy lento y, por lo tanto, se prefiere un método a una propiedad. En mi opinión, las clases derivadas de MarshalByRefObject nunca deben usar propiedades.

Entonces, si vemos que String.Length es propiedad y String.IsNullOrEmpty es un método que puede ejecutarse más rápido que la propiedad String.Length .

Answer 4

Es porque ejecutó su punto de referencia desde Visual Studio, lo que evita que el compilador JIT optimice el código. Sin optimizaciones, este código se produce para String.IsNullOrEmpty

00000000   push        ebp 
00000001   mov         ebp,esp 
00000003   sub         esp,8 
00000006   mov         dword ptr [ebp-8],ecx 
00000009   cmp         dword ptr ds:[00153144h],0 
00000010   je          00000017 
00000012   call        64D85BDF 
00000017   mov         ecx,dword ptr [ebp-8] 
0000001a   call        63EF7C0C 
0000001f   mov         dword ptr [ebp-4],eax 
00000022   movzx       eax,byte ptr [ebp-4] 
00000026   mov         esp,ebp 
00000028   pop         ebp 
00000029   ret 

y ahora compáralo con el código producido para Length == 0

00000000   push   ebp 
00000001   mov    ebp,esp 
00000003   sub    esp,8 
00000006   mov    dword ptr [ebp-8],ecx 
00000009   cmp    dword ptr ds:[001E3144h],0 
00000010   je     00000017 
00000012   call   64C95BDF 
00000017   mov    ecx,dword ptr [ebp-8] 
0000001a   cmp    dword ptr [ecx],ecx 
0000001c   call   64EAA65B 
00000021   mov    dword ptr [ebp-4],eax 
00000024   cmp    dword ptr [ebp-4],0 
00000028   sete   al 
0000002b   movzx  eax,al 
0000002e   mov    esp,ebp 
00000030   pop    ebp 
00000031   ret 

Puede ver, que el código para Length == 0 hace todo lo que hace el código para String.IsNullOrEmpty , pero adicionalmente intenta algo así como volver a convertir booleanamente el valor booleano (devuelto de la comparación de longitud) a boolean y esto lo hace más lento que String.IsNullOrEmpty .

Si compila un programa con las optimizaciones habilitadas (Modo de lanzamiento) y ejecuta el archivo .exe directamente desde Windows, el código generado por el compilador JIT es mucho mejor. Para String.IsNullOrEmpty es:

001f0650   push    ebp
001f0651   mov     ebp,esp
001f0653   test    ecx,ecx
001f0655   je      001f0663
001f0657   cmp     dword ptr [ecx+4],0
001f065b   sete    al
001f065e   movzx   eax,al
001f0661   jmp     001f0668
001f0663   mov     eax,1
001f0668   and     eax,0FFh
001f066d   pop     ebp
001f066e   ret

y para Longitud == 0 :

001406f0   cmp     dword ptr [ecx+4],0
001406f4   sete    al
001406f7   movzx   eax,al
001406fa   ret

Con este código, los resultados son los esperados, es decir, la longitud == 0 es ligeramente más rápida que String.IsNullOrEmpty .

También vale la pena mencionar que usar Linq, las expresiones lambda y el módulo de cómputo en su punto de referencia no es una buena idea, ya que estas operaciones son lentas (en comparación con la comparación de cadenas) y hacen que el punto de referencia sea inexacto.

Answer 5

Su punto de referencia no mide String.IsNullOrEmpty vs String.Length, sino cómo se generan las diferentes expresiones lambda para las funciones. Es decir, no es muy sorprendente que el delegado que solo contiene la función de llamada única (IsNullOrEmpty) sea más rápido que uno con función de llamada y comparación (Longitud == 0).

Para obtener una comparación de llamada activa, escriba el código que los llama directamente sin delegados.

EDITAR: Mis medidas aproximadas muestran que la versión delegada con IsNullOrEmpty es un poco más rápida que el resto, mientras que las llamadas directas a la misma comparación están en orden inverso (y casi dos veces más rápido debido a un número significativamente menor de código adicional) en mi máquina. Los resultados pueden desconfiar entre máquinas, modo x86 / x64, así como entre versiones de tiempo de ejecución. Por motivos prácticos, consideraría que las 4 formas son casi las mismas si necesita usarlas en las consultas LINQ.

En general, dudo que haya una diferencia mensurable en el programa real elegido por estos métodos, así que elija el que le resulte más legible y utilícelo. Generalmente prefiero IsNullOrEmpty ya que da menos oportunidad de obtener == /! = Incorrecto en una condición.

La eliminación de la manipulación de la cadena por completo desde el momento en que el código crítico probablemente generará una gran ventaja, ya que elegir entre estas opciones, y eliminar LINQ para el código crítico es una opción. Como siempre, asegúrese de medir la velocidad general del programa en el escenario de la vida real.

Answer 6

Tu prueba está mal en alguna parte. IsNullOrEmpty no puede ser más rápido por definición, ya que realiza una operación de comparación nula adicional y luego prueba la Longitud.

Entonces la respuesta puede ser: es más rápido debido a tu prueba. Sin embargo, incluso su código muestra que IsNullOrEmpty es sistemáticamente más lento en mi máquina en los modos x86 y x64.

Answer 7

puede ser causada por los tipos de las variables involucradas. * Vacío parece utilizar un valor booleano, longitud un int (supongo).

Paz !

• : editar