File.Exists es una operación costosa?

Question

Re: http://msdn.microsoft. com / es-es / 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 de gran tamaño?

Answer 1

Locking no. Lento, depende de lo que lo está comparando a. Es bastante barato por lo que yo / O va, pero de E / S es generalmente lenta global en comparación con otras operaciones. Por lo tanto, si tiene que usarlo, no va a doler demasiado malo. Sin embargo, yo trato de no llamar más veces de lo que es realmente necesario! : -)

Answer 2

En la informática, en realidad no hay tal cosa como una "operación costosa", a menos que se tiene en cuenta lo que es caro en relación a.

Por ejemplo, en el mundo real, sería $ 2.000.000 para un objeto ser caro? Lo que si es el precio de las Bahamas? ¿Sería caro, entonces? ¿Qué pasa con un cartón de leche? Es tan caro?

Lo que usted debe considerar es si File.Exists es costoso en términos de la operación global que pretende hacer, y si no que en realidad tienen ninguna alternativa.

Si usted no tiene ninguna alternativa, qué importa si es caro o no?

Por ejemplo, si haces 1 de verificación si existe el archivo, y luego, si lo hace, que lo almacenas en, y pasar una hora procesarla, entonces yo supongo que no sería considerado caro.

Sin embargo, si usted lo llama 10 veces en un solo lazo, para averiguar si existe un archivo, y luego, si lo hace, simplemente incrementar un número, entonces podría ser el más caro única operación que haces allí.

La única manera de saber con certeza es realmente medir el tiempo que toma llamada a un método, en comparación con lo demás que en la misma operación.

Answer 3

En el año 2016 no parece ser muy caro y hay también parece haber ninguna diferencia real entre File.Exists y PathFileExists ( Por qué es File.Exists () mucho más lento cuando no existe el archivo? ). 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");

}

Answer 4

No creo que es (operaciones de archivo están muy optimizados y almacenan en caché en la mayoría de los sistemas operativos) 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 al perfil realmente su aplicación y ver si se trata de un punto de acceso.

Answer 5

Mejor sería hacer algunas pruebas en su entorno. Tengo una aplicación que puede hacer 10.000 por segundo sin ningún problema a mis sistemas. Considero que bastante rápido.

Answer 6

File.Exisits con FindFirstFile kernel32.dll manejador abierta al archivo. Si mango resultante no es válida, devuélvalo falsa. Si es válido que se llene estructura de datos con todas las cosas por el estilo LastAccessTime, CreationTime, tamaño del archivo y así sucesivamente. Y luego de vuelta verdad. Nada de bloqueo.