¿Existe una operación costosa en File.Exists?

Question

Re: http://msdn.microsoft.com/en-us/library/system.io.file.exists.aspx

¿Alguien sabe si esto es una operación particularmente lenta o de bloqueo que podría afectar el rendimiento del servidor en un entorno grande?

Answer 1

Bloqueando no. Lento, depende de lo que lo comparas. Es bastante económico en lo que respecta a E/S, pero la E/S generalmente es lenta en comparación con otras operaciones. Entonces, si debe usarlo, no le dolerá mucho. ¡Sin embargo, trataría de no llamarlo más veces de lo que realmente es necesario! :-)

Answer 2

no creo que es (operaciones de archivo están muy optimizados y almacenan en caché en la mayoría de OS) y la mayoría de las otras operaciones son más propensos a ser culpables aquí (enchufes, acceso a base de datos, el tratamiento general, etc.). Pero, como de costumbre, la mejor manera es realmente perfilar su aplicación y ver si se trata de un punto de acceso.

Answer 3

File.Exisits con kernel32.dll FindFirstFile abre el controlador al archivo. Si el identificador resultante no es válido, devuelve falso. Si es válido, rellene la estructura de datos con todo lo relacionado, como LastAccessTime, CreationTime, tamaño de archivo, etc. Y luego regresa cierto. Nada bloqueando

Answer 4

Lo mejor sería realizar algunas pruebas en su entorno. Tengo una aplicación que puede hacer más de 10.000 por segundo sin ningún problema para mis sistemas. Lo considero bastante rápido.

Answer 5

En computación, en realidad no existe una "operación costosa", a menos que se tenga en cuenta lo caro que es.

Por ejemplo, en el mundo real, $ 2.000.000 para un objeto sería costoso? ¿Qué pasa si es el precio de Bahamas? ¿Sería caro entonces? ¿Qué tal un cartón de leche? ¿Eso es caro?

Lo que debe tener en cuenta es que File.Exists es costoso en términos de la operación general que pretende realizar, y si realmente tiene alguna alternativa.

Si no tiene ninguna alternativa, ¿importa si es cara o no?

Por ejemplo, si lo hace 1 compruebe si el archivo existe, y luego si lo hace, lo carga y pasa una hora procesándolo, entonces supongo que no se consideraría costoso.

Sin embargo, si lo llama 10 veces en un solo bucle, para averiguar si existe un archivo, y luego si lo hace, simplemente incremente un número, entonces podría ser la operación más cara que haga allí.

La única forma de que pueda estar seguro es en realidad medir cuánto tiempo lleva esa llamada de método, en comparación con el resto en la misma operación.

Answer 6

En el año 2016 no parece ser muy caro y hay también parece haber ninguna diferencia real entre File.Exists y PathFileExists (Why is File.Exists() much slower when the file does not exist?). La única diferencia que podía medir es que es más rápido para comprobar si un archivo no existente, entonces uno ya existente:

(Probado en un SSD)

[DllImport("Shlwapi.dll", SetLastError = true, CharSet = CharSet.Auto)] 
private extern static bool PathFileExists(StringBuilder path); 

void Main() 
{ 
    var sw = Stopwatch.StartNew(); 
    for (int i = 0; i < 10000; i++) 
    { 
     File.Exists(@"c:\Home\Temp\test_.log"); 
    } 
    sw.Stop(); 
    sw.Dump("File.Exists = false"); 

    sw = Stopwatch.StartNew(); 
    for (int i = 0; i < 10000; i++) 
    { 
     File.Exists(@"c:\Home\Temp\test.log"); 
    } 
    sw.Stop(); 
    sw.Dump("File.Exists = true"); 

    var sb = new StringBuilder(@"c:\Home\Temp\test_.log"); 
    sw = Stopwatch.StartNew(); 
    for (int i = 0; i < 10000; i++) 
    { 
     PathFileExists(sb); 
    } 
    sw.Stop(); 
    sw.Dump("PathFileExists = false"); 

    sb = new StringBuilder(@"c:\Home\Temp\test.log"); 
    sw = Stopwatch.StartNew(); 
    for (int i = 0; i < 10000; i++) 
    { 
     PathFileExists(sb); 
    } 
    sw.Stop(); 
    sw.Dump("PathFileExists = true"); 

}