¿Hay una gran diferencia de rendimiento entre:Pipe vs. archivo temporal
Tengo curiosidad por saber cuál es la respuesta para Windows y * nix.
EDITAR: Debería haber preguntado: ¿La memoria caché del búfer elimina la diferencia entre un archivo temporal y un conducto?
Una gran diferencia es que con la tubería, los procesos A y B pueden ejecutarse al mismo tiempo, por lo que B comienza a trabajar en la salida de A antes de que A termine de producirla. Además, el tamaño de la tubería es limitado, por lo que A no podrá producir mucha más información de la que B ha consumido; se hará esperar a que B se ponga al corriente.
Si el volumen de datos es grande, escribir en el archivo temporal implica actividad del disco, aunque solo sea para crear y luego destruir el archivo. Es posible que los datos permanezcan en los grupos de búferes en memoria, por lo que no hay E/S de disco allí, incluso para archivos sorprendentemente grandes. Escribir en la tubería 'nunca' implica escribir en el disco.
La gran diferencia es que el primer método realmente utiliza almacenamiento en disco, mientras que un conducto usará memoria (a menos que sea realmente pedante y empiece a pensar en el espacio de intercambio).
En cuanto a rendimiento, la memoria es más rápida que el disco (casi siempre). Esto debería ser generalmente cierto para todos los sistemas operativos.
El único momento cuando se usa un archivo temporal realmente tiene sentido es si el proceso B tiene que examinar los datos en varias pasadas (como ciertos tipos de codificación de video). Para este uso, toda la secuencia de datos debería almacenarse en búfer y si hubiera suficientes datos sí, probablemente anularía la ventaja de la memoria. Por lo tanto, para las operaciones de paso múltiple (búsqueda de destino), vaya con un archivo temporal.
Ver, me preguntaba si la memoria caché de disco eliminaría la diferencia entre las tuberías y un archivo temporal. –
El gran problema es este: mientras que el proceso A escribe en un * archivo *, el proceso B no hará nada (hasta que esté listo). Mientras que el proceso A está escribiendo en una * tubería *, el proceso B puede comenzar a leer de inmediato. Entonces, incluso si el sistema operativo almacena en caché todo el archivo, aún tendrá que esperar hasta que A haya terminado. Y sí, es posible "transmitir" un archivo (como tail -f lo hace) pero aún tienes que esperar que A se enjuague antes de que veas algo. Entonces, de nuevo, usa una tubería a menos que necesites hacer búsquedas. –
@Chris No creo que el proceso B tenga que esperar hasta que el proceso A se haya descargado al archivo. Si el proceso B comienza a leer el archivo incluso antes de que el proceso A haya terminado, no pasa nada malo. la solicitud del proceso B se cumplirá desde el propio buffer. No necesita esperar hasta que los cambios se hayan confirmado en el disco. ¿O estoy equivocado aquí? –
A menos que mi comprensión de las tuberías esté completamente fuera de la pared, la respuesta es SÍ.
Escribir en un archivo temporal implica acceso al disco y la sobrecarga asociada.
Escribir en una tubería, y leer de ella, ocurre en la memoria. Mucho mas rápido.
Pensé que una respuesta práctica podría ayudar. Estoy optimizando la velocidad de un script que uso que tiene alrededor de 4 pasos. Lo configuré para utilizar métodos de tuberías y sin tuberías. Esto es en Windows 7 de 64 bits.
Tengo un 3% de ralentización por no usar tuberías. Lo cual vale la pena, para mí, porque ahora puedo detenerme entre cada paso y actualizar el título de la ventana, lo que no pude hacer cuando era todo un comando.
Personalmente, tomaré ese 3% de aciertos para los títulos de las ventanas.
Como curiosidad, guardo un archivo de> 20M, y luego lo paso a un script especializado de Perl que modifica los resultados, luego los ordena usando ventanas integradas en SORT.EXE, luego los separa usando UNIQ.EXE de cygwin, luego vuelve a gregar los mismos resultados para obtener grep-result-coloring de ANSI. La mayor parte del tiempo se gasta en la fase de clasificación.
¿De qué títulos de Windows estás hablando? ¿Es esta parte del flujo que mencionaste en tu respuesta? – Cristik
Sí, tengo algunos scripts que tardan unos segundos, por lo que actualizan el título de la ventana de línea de comandos para darme algo que ver [cuando se minimiza] y no me inquieta que no esté haciendo nada :) – ClintL
Nota que un comando de clasificación es un bloqueador de concurrencia. No puede producir ningún resultado hasta que haya leído toda su entrada. Teniendo en cuenta eso y su comentario de que la mayor parte del tiempo se gasta en la fase de clasificación, no es sorprendente que haya un cambio de rendimiento muy pequeño entre el flujo de control por tubería y el flujo de control no por tubería. Si su canalización no tiene una clasificación de bloqueo, es posible que demuestre mayores ahorros en el tiempo de procesamiento a partir de la mayor concurrencia. –
+1: lo único que no responde explícitamente es si esto es lo mismo para Windows y Unix. (Dudo que hubiera una diferencia, pero estaba en la pregunta original.) – OverZealous
@OverZealous: punto justo. Mi respuesta se aplica de manera más confiable a Unix que a Windows. Windows a veces obtiene aproximadamente el mismo resultado de forma ligeramente diferente a Unix, pero creo que mis puntos son válidos en Windows. Estoy menos seguro de que un conducto de Windows nunca involucre escribir en el disco. –