No, un archivo no se lee automáticamente en la memoria abriéndolo. Eso sería terriblemente ineficiente. sed, por ejemplo, lee su entrada línea por línea, al igual que muchas otras herramientas de Unix. Rara vez tiene que mantener más que la línea actual en la memoria.
Con awklo mismo. Lee un registro a la vez, que por defecto es una línea. Si almacena partes de los datos de entrada en variables, eso será adicional, por supuesto 1 .
Algunas personas tienen la costumbre de hacer cosas como
for line in $(cat file); do ...; done
Puesto que la cáscara se tenga que ampliar la $(cat file)sustitución de orden completamente antes de ejecutar incluso la primera iteración del forbucle, este será leer el conjunto de fileen la memoria (en la memoria utilizada por la cáscara de ejecutar el forbucle). Esto es un poco tonto y también poco elegante. En cambio, uno debería hacer
while IFS= read -r line; do ...; done <file
Esto procesará filelínea por línea (pero lea Entendiendo "IFS = read -r line" ).
Sin embargo, rara vez se necesita procesar archivos línea por línea en el shell, ya que la mayoría de las utilidades están orientadas a la línea de todos modos (consulte ¿Por qué usar un bucle de shell para procesar texto se considera una mala práctica? ).
Estoy trabajando en bioinformática y, al procesar grandes cantidades de datos genómicos, no podría hacer mucho a menos que solo mantuviera los bits de datos que eran absolutamente necesarios en la memoria. Por ejemplo, cuando necesito eliminar los bits de datos que podrían usarse para identificar individuos de un conjunto de datos de 1 terabyte que contiene variantes de ADN en un archivo VCF (porque ese tipo de datos no puede hacerse público), lo hago línea por línea. procesamiento con un awkprograma simple (esto es posible ya que el formato VCF está orientado a líneas). ¡ No leo el archivo en la memoria, lo proceso allí y lo vuelvo a escribir! Si el archivo se comprimiera, lo alimentaría zcato gzip -d -c, lo que, dado que gzipno procesa los datos, tampoco leería todo el archivo en la memoria.
Incluso con formatos de archivo que no están orientados a la línea, como JSON o XML, existen analizadores de flujo que permiten procesar grandes archivos sin almacenarlo todo en la RAM.
Con los ejecutables, es un poco más complicado ya que las bibliotecas compartidas pueden cargarse a pedido y / o compartirse entre procesos (consulte Carga de bibliotecas compartidas y uso de RAM , por ejemplo).
El almacenamiento en caché es algo que no he mencionado aquí. Esta es la acción de usar RAM para contener datos de acceso frecuente. El sistema operativo puede almacenar en caché archivos más pequeños (por ejemplo, ejecutables) con la esperanza de que el usuario haga muchas referencias a ellos. Además de la primera lectura del archivo, los accesos posteriores se realizarán en la RAM en lugar de en el disco. El almacenamiento en caché, como el almacenamiento en búfer de entrada y salida, generalmente es en gran medida transparente para el usuario y la cantidad de memoria utilizada para almacenar en caché puede cambiar dinámicamente dependiendo de la cantidad de RAM asignada por las aplicaciones, etc.
1 Técnicamente, la mayoría de los programas probablemente leen una porción de los datos de entrada a la vez, ya sea utilizando el almacenamiento en búfer explícito o implícitamente a través del almacenamiento en búfer que hacen las bibliotecas de E / S estándar, y luego presentan esa porción en línea al código del usuario. Es mucho más eficiente leer un múltiplo del tamaño de bloque del disco que, por ejemplo, un carácter a la vez. Sin embargo, este tamaño de fragmento rara vez será mayor que un puñado de kilobytes.