Recabamos por todo internet para así mostrarte la respuesta para tu duda, si tienes dudas puedes dejarnos la inquietud y te contestamos con mucho gusto, porque estamos para servirte.
Solución:
Seguimiento de la ejecución de nautilus muestra que la lentitud se debe a una combinación de dos factores:
-
Es inteligente para mostrar información útil sobre cada archivo. Mira dentro del contenido de los archivos para determinar qué ícono usar y posiblemente mostrar una vista previa. Esto se puede atenuar desactivando las vistas previas en las preferencias.
-
Hace mucho trabajo inútil (como
stating cada archivo varias veces, y comprobando/proc/filesystemsincluso para no directorios). Todo lo que puedes hacer es aprender a programar, mejorar el programa y enviar un parche. O al menos envíe a los autores una solicitud de función (hágalo más rápido). -
Llama a varios procesos externos para cada directorio, no he explorado lo que hacen.
En la pestaña “Vista previa” en “Editar -> Preferencias”, intente cambiar todas las opciones a “Nunca”.
También me ayudó enormemente desactivar las “Tecnologías de asistencia”. Puede hacerlo en “Sistema -> Preferencias -> Tecnologías de asistencia”. Desmarque “Habilitar tecnologías de asistencia”.
Deberá cerrar la sesión y volver a iniciarla para que el último cambio surta efecto.
Esto me recordó una conversación que tuve con Alexander Larsson, el desarrollador principal de Nautilus y otros proyectos, incluido GVFS.
Giles su respuesta, específicamente la parte sobre Nautilus mirando dentro del contenido de los archivos, toca la razón principal por la que Nautilus es “lento”. Sin embargo Giles no explica por qué esto es lento, lo que puede ser obvio para algunos, pero no para otros. Esto es lo que Alex tenía que decir:
Digamos que comienza con una pizarra en blanco, es decir, no ha accedido al sistema de archivos en absoluto. Ahora diga que ejecuta stat(“/some/dir/file”). Primero, el kernel tiene que encontrar el archivo, que en términos técnicos se llama inodo. Comienza buscando en el superbloque del sistema de archivos, que almacena el inodo del directorio raíz. Luego abre el directorio raíz, encuentra “algunos”, abre eso, encuentra “dir”, etc. finalmente encuentra el inodo para el archivo.
Entonces tienes que leer los datos del inodo. Después de la primera lectura, esto también se almacena en caché en la RAM. Entonces, una lectura solo tiene que ocurrir una vez.
Piense en el HD como un viejo tocadiscos, una vez que esté en el lugar correcto con la aguja, puede seguir leyendo cosas rápidamente mientras gira. Sin embargo, una vez que necesitas moverte a un lugar diferente, llamado “buscar”, estás haciendo algo muy diferente. Debe mover físicamente el brazo, luego esperar a que el plato gire hasta que el lugar correcto esté debajo de la aguja. Este tipo de movimiento físico es inherentemente lento, por lo que los tiempos de búsqueda de los discos son bastante largos.
Entonces, ¿cuándo buscamos? Depende del diseño del sistema de archivos, por supuesto. Los sistemas de archivos intentan almacenar archivos consecutivamente para aumentar el rendimiento de lectura, y generalmente también intentan almacenar inodos para un solo directorio cerca uno del otro, pero todo depende de cosas como cuándo se escriben los archivos, fragmentación del sistema de archivos, etc. Entonces, en el peor de los casos caso, cada estadística de un archivo provocará una búsqueda y luego cada apertura del archivo provocará una segunda búsqueda. Entonces, es por eso que las cosas toman tanto tiempo cuando no se almacena nada en caché.
Algunos sistemas de archivos son mejores que otros, la desfragmentación podría ayudar. Puedes hacer algunas cosas en las aplicaciones. Por ejemplo, GIO ordena los inodos recibidos de readdir() antes de indicarlos con la esperanza de que el número de inodo tenga algún tipo de relación con el orden del disco (generalmente la tiene), minimizando así las búsquedas aleatorias de ida y vuelta.
Una cosa importante es diseñar su almacenamiento de datos y aplicaciones para minimizar la búsqueda. Por ejemplo, esta es la razón por la cual la lectura de /usr/bin de Nautilus es lenta, porque los archivos allí generalmente no tienen extensión, necesitamos hacer un rastreo mágico para cada uno. Entonces, necesitamos abrir cada archivo => una búsqueda por archivo => despacio. Otro ejemplo son las aplicaciones que almacenan información en muchos archivos pequeños, como solía hacer gconf, también una mala idea. De todos modos, en la práctica no creo que puedas hacer mucho más que tratar de ocultar las latencias.
Terminó con la siguiente nota:
La solución real para todo este dilema es alejarse de los medios rotativos. Escuché que los SSD de Intel son increíbles. Linus jura por ellos.
🙂
Nos puedes añadir valor a nuestro contenido contribuyendo tu experiencia en las referencias.