perché nautilus è lento?


19

Mi chiedo perché Nautilus sia molto lento quando si apre una directory che contiene molti file. La mia directory / usr / lib per esempio ha 1900 file e ci vogliono circa 5+ secondi per mostrare tutto. È stato così da quando ho installato Ubuntu qualche mese fa ed è davvero abbastanza fastidioso a volte. Non ho hardware potente ma so che Windows Explorer è molto più veloce di così.

C'è qualcosa che può essere fatto per accelerarlo?

Ubuntu 10.04


1
La mia ipotesi sarebbe che Nautilus utilizza ls per fare la sua lista mentre Explorer ha una cache.
digitxp

Che tipo di sistema è? Penso che questo sia un grande fattore. Sarebbe "lento" sul mio netbook, ma non tanto su un i7 con 4 + GB di RAM.
Chris,

Correlato su Chiedi a Ubuntu: Nautilus è molto lento
slhck

Risposte:


27

Tracciare l'esecuzione di nautilusmostra che la lentezza è dovuta a una combinazione di due fattori:

  • È intelligente visualizzare informazioni utili su ciascun file. Cerca all'interno del contenuto dei file per determinare quale icona utilizzare e possibilmente mostrare un'anteprima. Questo può essere attenuato disattivando le anteprime nelle preferenze.

  • Fa un sacco di lavoro inutile (come ad esempio il statsalvataggio di ogni file più volte e il controllo /proc/filesystemsanche di non directory). Tutto quello che puoi fare è imparare la programmazione, migliorare il programma e inviare una patch. O almeno invia agli autori una richiesta di funzionalità (rendila più veloce).

  • Chiama diversi processi esterni per ogni directory, non ho esplorato quello che fanno.


Buona risposta: D! +1 per patching + featurerequestrequest: D
BloodPhilia

Sono un programmatore, anche se non ancora abbastanza bravo da contribuire. Solo per curiosità, come hai fatto la traccia?
Distretto di codifica

2
@Derek: strace -f -ttt -p1234 -o nautilus.stracedove 1234 è il pid di nautilus. Non ho analizzato la traccia in dettaglio, ho solo dato un'occhiata al lead up (molte cose che coinvolgono sottoprocessi) e alle cose per file (più stats, e una openper alcuni file).
Gilles 'SO- smetti di essere malvagio'

1
Molte stat () multiple provengono da chiamate in libreria, molte da glibc.
Tim Post

woah, questo è un problema da oltre 6 anni! come mai nessuno ha investito il tempo in questo? Per cominciare, anteprime e statistiche dovrebbero essere fatte DOPO elencare i file. Pertanto, elencare enormi cartelle sarà istantaneo lse la navigazione sarà possibile durante il caricamento delle anteprime. Esplora risorse funziona in questo modo, se ricordo bene. Un po 'incredibile per un programma Ubuntu molto usato come questo. tuttavia, non dovrei lamentarmi ma contribuire invece
phil294

5

Nella scheda "Anteprima" in "Modifica -> Preferenze", prova a cambiare tutte le opzioni su "Mai".

Mi ha anche aiutato enormemente a disattivare "Tecnologie assistive". Puoi farlo in "Sistema -> Preferenze -> Tecnologie assistive". Deseleziona "Abilita tecnologie assistive".

Dovrai disconnetterti e riconnetterti per rendere effettiva l'ultima modifica.


Questo mi dà miglioramenti molto modesti. L'eliminazione dei segnalibri ha fatto una differenza molto maggiore.
Peter Jenkins,

5

Questo mi ha ricordato un colloquio che ho avuto con Alexander Larsson , lo sviluppatore principale di Nautilus e altri progetti tra cui GVFS.

La sua risposta , in particolare quella di Nautilus che guarda all'interno del contenuto dei file, tocca il motivo principale per cui Nautilus è "lento". Tuttavia Giles non spiega perché questo è lento, il che potrebbe essere ovvio per alcuni, ma non per altri. Ecco cosa ha detto Alex:

Supponi di iniziare con una tabula rasa, cioè non hai affatto avuto accesso al filesystem. Ora dite di eseguire stat ("/ some / dir / file"). Innanzitutto il kernel deve trovare il file, che in termini tecnici è chiamato inode. Inizia guardando nel superblocco del filesystem, che memorizza l'inode della directory root. Quindi apre la directory root, trova "some", apre quella, trova "dir", ecc. Alla fine trova l'inode per il file.

Quindi devi effettivamente leggere i dati dell'inode. Dopo la prima lettura questo è anche memorizzato nella cache nella RAM. Quindi, una lettura deve avvenire solo una volta.

Pensa all'HD come a un vecchio giradischi, una volta che sei nel posto giusto con l'ago puoi continuare a leggere le cose velocemente mentre ruota. Tuttavia, una volta che hai bisogno di trasferirti in un posto diverso, chiamato "cercare" stai facendo qualcosa di molto diverso. È necessario spostare fisicamente il braccio, quindi attendere che il piatto ruoti fino a quando il punto giusto si trova sotto l'ago. Questo tipo di movimento fisico è intrinsecamente lento, quindi i tempi di ricerca dei dischi sono piuttosto lunghi.

Quindi, quando cerchiamo? Dipende ovviamente dal layout del filesystem. I filesystem cercano di archiviare i file consecutivamente per aumentare le prestazioni di lettura e generalmente cercano anche di archiviare gli inode per una singola directory vicini l'uno all'altro, ma tutto dipende da cose come quando i file vengono scritti, frammentazione del filesystem, ecc. Quindi, nel peggiore dei casi caso, ogni stat di un file provocherà una ricerca e quindi ogni apertura del file provocherà una seconda ricerca. Quindi, ecco perché le cose impiegano così tanto tempo quando nulla viene memorizzato nella cache.

Alcuni filesystem sono migliori di altri, la deframmentazione potrebbe aiutare. Puoi fare alcune cose nelle app. Ad esempio, GIO ordina gli inode ricevuti da readdir () prima di dichiararli sperando che il numero di inode abbia una sorta di relazione con l'ordine del disco (generalmente ha) minimizzando così le ricerche casuali avanti e indietro.

Una cosa importante è progettare l'archiviazione dei dati e le app per ridurre al minimo la ricerca. Ad esempio, questo è il motivo per cui la lettura / usr / bin di Nautilus è lenta, poiché i file in essa contenuti in genere non hanno estensione, per ciascuno di essi è necessario eseguire uno sniffing magico. Quindi, dobbiamo aprire ogni file => una ricerca per file => slooooow. Un altro esempio sono le app che memorizzano informazioni in molti piccoli file, come una volta gconf, una cattiva idea. Ad ogni modo, in pratica non credo che ci sia molto da fare se non provare a nascondere le latenze.

Si è concluso con la seguente nota:

La vera soluzione di tutto questo dilemma è allontanarsi dai media rotanti. Ho sentito che gli SSD Intel sono fantastici. Linus giura per loro.

:-)


3
Interessante :) Tuttavia, se cercare è la causa principale della lentezza, mi chiedo ancora perché Windows Explorer sia molto più veloce di allora? Certamente non a causa dell'hardware.
Coding District,

4
Se dovessi indovinare, direi che non esegue sniffing magico, ma semplicemente rileva i file in base all'estensione (posso confermarlo per Windows XP).
Bruce van der Kooij,

2
Esattamente. Explorer (per la maggior parte) non esegue alcun tipo di sniffing dei file, utilizza semplicemente l'estensione. Se ha bisogno di renderizzare un'anteprima o leggere un'icona, beh, allora deve aprire il file. Puoi vederlo se apri una cartella di grandi dimensioni piena di file .exe. Un'estensione shell potrebbe costringere Explorer ad aprire un file per eseguire anche un po 'di sniffing. Ad esempio, alcune utility di archiviazione esamineranno i file .exe per vedere se sono archivi SFX. La MS ha investito molto nel fare le cose per cercare di accelerare Explorer, sia nella velocità effettiva che in quella apparente.
Afrazier,

3

Alla fine ho capito cosa rende Nautilus così lento: i segnalibri.

Per risolvere il problema, elimina tutti i segnalibri, riavvia e quindi aggiungi di nuovo quelli senza i quali non puoi vivere.

Usando strace mi sono reso conto che nautilus stava dichiarando molti file per ogni vista. Anche i file che non erano nella directory che stavo sfogliando durante la traccia. Penso che nautilus stia cercando di pre-memorizzare questi segnalibri.

Avevo un disco di rete come segnalibro ... questo potrebbe essere stato il motivo per cui nautilus impiegava diversi secondi per caricare.


1

Prova a utilizzare un file manager alternativo come Thunar. Thunar è molto più veloce nel caricare elenchi di directory e più stabile per la copia di file dal mio disco rigido USB NTFS su ext4, anche se con grandi set di file sembra avere problemi come Nautilus.

Ecco un link per lo script switch https://help.ubuntu.com/community/DefaultFileManager


Ottima soluzione! Adoro il "sudo apt-get install thunar" e le "applicazioni preferite per exo", quindi seleziona Thunar nella soluzione (Utilità> File Manager).
Doud,

1

Se hai installato xfce in un sistema Gnome e non lo usi mai, rimuovi exo-utils

Ha risolto il mio problema, insieme al problema di Chrome che non apriva correttamente i file dopo il download.


Non mi ha aiutato. exo-utils è richiesto anche da molti pacchetti incluso il pacchetto xfdesktop4, quindi è abbastanza difficile da rimuovere: sudo dpkg -r --ignore-depend = xfce4-terminal, thunar-volman, squeeze, thunar, xfce4-panel, xfce4-verve -plugin, xfdesktop4 exo-utils
Peter Jenkins,

1

Nella scheda "Anteprima" in "Modifica -> Preferenze", prova a cambiare tutte le opzioni su "Mai".

Mi ha anche aiutato enormemente a disattivare "Tecnologie assistive". Puoi farlo in "Sistema -> Preferenze -> Tecnologie assistive". Deseleziona "Abilita tecnologie assistive".

Dovrai disconnetterti e riconnetterti per rendere effettiva l'ultima modifica.


1
Il tempo per aprire una cartella di grandi dimensioni è stato ridotto da circa 30 secondi a forse due secondi. Santo cielo.
wsmart,

Il mio post è stato eliminato qui da un altro utente. apparentemente. Volevo dire grazie a Jay per il suo post in quanto ha fatto un'enorme differenza per il mio lento problema di Nautius. Sii reale, sii sobrio.
wsmart,
Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.