Diferencia de rendimiento entre stdin y argumento de línea de comando

Para algunos comandos, es posible especificar cierta entrada como stdin o un argumento de línea de comando.

Específicamente, suponga que commandpuede tomar la entrada estándar y un nombre de archivo como argumento de línea de comando command < myfile, cat myfile | command y command myfilepuede producir el mismo resultado.

Por ejemplo,

Cuando el comando es sed:

sed s/day/night/ <myfile >new   
sed s/day/night/ myfile >new    
cat myfile | sed s/day/night/ >new

Cuando el comando es cat:

cat < myfile
cat myfile

1. Me preguntaba si hay algunas reglas generales sobre sus actuaciones, es decir, ¿cuál de ellas suele ser la más eficiente y la que menos?
2. ¿La redirección siempre es mejor que la tubería?

La cat file | commandsintaxis se considera un uso inútil deCat . De todas sus opciones, se necesita un golpe de rendimiento porque tiene que generar otro proceso en el núcleo. Por insignificante que esto pueda resultar en el panorama general, está sobrecargado que las otras formas no tienen. Esto se ha cubierto en preguntas como: ¿Debería preocuparme por los gatos innecesarios?

Entre las otras dos formas, prácticamente no hay diferencias de rendimiento. STDIN es un nodo de archivo especial que el proceso tiene que abrir y leer como cualquier otro. Pasar un nombre de archivo en lugar de STDIN solo hace que abra un archivo diferente.

La diferencia estaría en qué características / flexibilidad está buscando.

• Pasar el nombre del archivo al programa significaría que el archivo de entrada era buscable. Esto puede o no ser importante para el programa, pero algunas operaciones pueden acelerarse si la secuencia es buscable.
• Conocer el archivo de entrada real le permite a su programa escribir en él. Por ejemplo, sed -ipara la edición in situ. (Nota: dado que esto tiene que crear un nuevo archivo detrás de escena, no es una ganancia de rendimiento sobre otros redireccionamientos, pero es un paso conveniente).
• El uso de redireccionamientos de shell le brinda la capacidad de concatenar múltiples archivos o incluso utilizar la redirección de procesos. sed [exp] < file1 file2o incluso sed [exp] < <(grep command). Los detalles de este caso de uso se pueden encontrar en esta pregunta: sustitución del proceso y tubería

1. Dado que command filesolo abre el archivo y desde entonces funciona como si lo fuera stdin, hay poca diferencia. Con la redirección de shell, simplemente abre el archivo de antemano (shell lo hace) en lugar del comando binario en sí.

2. Si estamos hablando de cat file | commandvs. command <file, entonces este último es el preferido. No notará una diferencia de rendimiento significativa entre los dos, pero el primero es innecesariamente complicado (proceso adicional y búfer de memoria compartida para la tubería, con rendimiento limitado). Además, no puede seek(cambiar la posición del puntero del archivo arbitrariamente) en un tubería, mientras que puede en un archivo ordinario. Algunos comandos pueden usar un algoritmo más eficiente cuando seekes posible hacer ting en el archivo de entrada.