por que o nautilus é lento?


19

Estou me perguntando por que o Nautilus é muito lento ao abrir um diretório que contém muitos arquivos. Meu diretório / usr / lib, por exemplo, possui 1900 arquivos e leva aproximadamente 5 segundos para mostrar tudo. Tem sido assim desde que eu instalei o Ubuntu há alguns meses e às vezes é realmente muito chato. Não tenho hardware poderoso, mas sei que o Windows Explorer é muito mais rápido que isso.

Existe algo que possa ser feito para acelerar isso?

Ubuntu 10.04


1
Meu palpite seria que o Nautilus utiliza ls para fazer sua lista enquanto o Explorer tem um cache.
digitxp

Que tipo de sistema é esse? Eu acho que isso é um grande fator. Seria "lento" no meu netbook, mas não tanto em um i7 com 4 GB de RAM.
Chris

Related on Ask Ubuntu: Nautilus is very slow
slhck 31/01

Respostas:


27

O rastreamento da execução de nautilusmostra que a lentidão se deve a uma combinação de dois fatores:

  • É inteligente exibir informações úteis sobre cada arquivo. Ele examina o conteúdo dos arquivos para determinar qual ícone usar e, possivelmente, mostra uma visualização. Isso pode ser atenuado desativando as visualizações nas preferências.

  • Faz muito trabalho inútil (como statinserir cada arquivo várias vezes e verificar /proc/filesystemsaté mesmo não diretórios). Tudo o que você pode fazer é aprender a programar, melhorar o programa e enviar um patch. Ou, pelo menos, envie uma solicitação de recurso aos autores (por favor, seja mais rápido).

  • Ele chama vários processos externos para cada diretório, não explorei o que eles fazem.


Boa resposta: D! +1 para aplicação de patches + featurerequestrequest: D
BloodPhilia

Sou programador, embora ainda não seja bom o suficiente para contribuir. Só por curiosidade, como você fez o rastreamento?
Coding District

2
@ Derek: strace -f -ttt -p1234 -o nautilus.straceonde 1234 é o pid do nautilus. Não analisei o rastreio em detalhes, apenas observei o lead up (muitas coisas envolvendo subprocessos) e as coisas por arquivo (vários se statum openpara alguns arquivos).
Gilles 'SO- stop be evil'

1
Muitos dos stat () múltiplos são provenientes de chamadas de biblioteca, muitos da glibc.
Tim Post

uau, isso tem sido um problema desde mais de 6 anos! como é que ainda ninguém investiu tempo nisso? Para começar, as visualizações e estatísticas devem ser feitas DEPOIS de listar os arquivos. Assim, listar pastas enormes será o mais instantâneo lspossível e a navegação será possível enquanto as visualizações estiverem sendo carregadas. O Windows Explorer funciona assim, se bem me lembro. É inacreditável para um programa Ubuntu altamente usado como esse. no entanto, não deve reclamar, mas contribuir vez
phil294

5

Na guia "Visualizar" em "Editar -> Preferências", tente alternar todas as opções para "Nunca".

Também me ajudou enormemente a desativar as "Tecnologias Assistivas". Você pode fazer isso em "Sistema -> Preferências -> Tecnologias Assistivas". Desmarque a opção "Ativar tecnologias de assistência".

Você precisará sair e fazer login novamente para que a última alteração entre em vigor.


Isso me dá melhorias muito modestas. A exclusão de favoritos fez uma diferença muito maior.
Peter Jenkins

5

Isso me lembrou de uma conversa que tive com Alexander Larsson , o desenvolvedor líder do Nautilus e outros projetos, incluindo o GVFS.

Giles, sua resposta , especificamente sobre o Nautilus ver dentro do conteúdo dos arquivos, aborda a principal razão pela qual o Nautilus é "lento". No entanto, Giles não explica por que isso é lento, o que pode ser óbvio para alguns, mas não para outros. Aqui está o que Alex tinha a dizer:

Digamos que você comece com uma folha em branco, ou seja, você não acessou o sistema de arquivos. Agora diga que você executa stat ("/ some / dir / file"). Primeiro, o kernel precisa encontrar o arquivo, que em termos técnicos é chamado de inode. Começa procurando no superbloco do sistema de arquivos, que armazena o inode do diretório raiz. Em seguida, ele abre o diretório raiz, encontra "alguns", abre isso, encontra "dir" etc., eventualmente, encontrando o inode para o arquivo.

Então você precisa realmente ler os dados do inode. Após a primeira leitura, isso também é armazenado em cache na RAM. Portanto, apenas uma leitura precisa acontecer uma vez.

Pense no HD como um toca-discos antigo, quando estiver no lugar certo com a agulha, você poderá continuar lendo as coisas rapidamente enquanto ele gira. No entanto, quando você precisa se mudar para um lugar diferente, chamado de "procurar", está fazendo algo muito diferente. Você precisa mover fisicamente o braço e esperar o prato girar até que o lugar certo esteja embaixo da agulha. Esse tipo de movimento físico é inerentemente lento, portanto, os tempos de busca dos discos são bem longos.

Então, quando procuramos? Depende do layout do sistema de arquivos, é claro. Os sistemas de arquivos tentam armazenar arquivos consecutivamente para aumentar o desempenho da leitura, e geralmente também tentam armazenar inodes para um único diretório próximo, mas tudo depende de coisas como quando os arquivos são gravados, fragmentação do sistema de arquivos etc. Nesse caso, cada estatística de um arquivo fará uma busca e, em seguida, cada abertura do arquivo fará uma segunda busca. Portanto, é por isso que as coisas demoram tanto tempo quando nada é armazenado em cache.

Alguns sistemas de arquivos são melhores que outros, a desfragmentação pode ajudar. Você pode fazer algumas coisas nos aplicativos. Por exemplo, o GIO classifica os inodes recebidos de readdir () antes de declará-los, esperando que o número do inode tenha algum tipo de relação com a ordem do disco (geralmente possui), minimizando assim as buscas aleatórias.

Uma coisa importante é projetar seu armazenamento de dados e aplicativos para minimizar a busca. Por exemplo, é por isso que o Nautilus reading / usr / bin é lento, porque os arquivos lá geralmente não têm extensão, precisamos fazer um sniffing mágico para cada um. Portanto, precisamos abrir cada arquivo => uma busca por arquivo => slooooow. Outro exemplo são os aplicativos que armazenam informações em muitos arquivos pequenos, como o gconf costumava fazer, também uma má idéia. De qualquer forma, na prática, acho que não há muito que você possa fazer, exceto tentar ocultar as latências.

Ele terminou com a seguinte nota:

A verdadeira solução para todo esse dilema é afastar-se da mídia rotativa. Ouvi dizer que os SSDs da Intel são impressionantes. Linus jura por eles.

:-)


3
Interessante :) No entanto, se a busca é a causa raiz da lentidão, ainda estou me perguntando por que o Windows Explorer é muito mais rápido, então? Certamente não devido ao hardware.
Coding District

4
Se eu tivesse que adivinhar, diria que não faz farejamento mágico, mas simplesmente detecta arquivos com base na extensão (posso confirmar isso no Windows XP).
Bruce van der Kooij 18/08/10

2
Exatamente. O Explorer (na maior parte) não faz nenhum tipo de farejamento de arquivo, ele simplesmente usa a extensão. Se precisar renderizar uma visualização ou ler um ícone, então é necessário abrir o arquivo. Você pode ver isso se abrir uma pasta grande cheia de arquivos .exe. Uma extensão de shell pode forçar o Explorer a abrir um arquivo para também farejar. Por exemplo, alguns utilitários de arquivamento examinam arquivos .exe para verificar se são arquivos SFX. A MS investiu muito esforço para tentar acelerar o Explorer, tanto na velocidade real quanto na aparente.
21711

3

Finalmente descobri o que está tornando o nautilus tão lento: favoritos.

Para corrigi-lo, exclua todos os seus favoritos, reinicie e adicione novamente os que você não pode viver.

Usando strace, percebi que o nautilus estava declarando muitos arquivos para todas as visualizações. Mesmo arquivos que não estavam no diretório, eu estava navegando durante o rastreamento. Acho que o nautilus está tentando pré-armazenar em cache esses indicadores.

Eu tinha uma unidade de rede como marcador ... essa pode ter sido a razão pela qual o nautilus estava demorando alguns segundos para carregar.


1

Tente usar um gerenciador de arquivos alternativo como o Thunar. O Thunar é muito mais rápido no carregamento de listagens de diretórios e mais estável para copiar arquivos do meu disco rígido USB NTFS para o ext4, embora com grandes conjuntos de arquivos pareça ter problemas como o Nautilus.

Aqui está um link para o script de switch https://help.ubuntu.com/community/DefaultFileManager


Ótima solução alternativa! Eu amo o "sudo apt-get install thunar" e "exo-preferido-aplicativos" e selecione Thunar na solução (Utilitários> Gerenciador de arquivos).
Doud

1

Se você possui o xfce instalado em um sistema Gnome e nunca o usa, remova exo-utils

Foi corrigido o meu problema, juntamente com o problema do Chrome não abrir arquivos corretamente após o download.


Não ajudou para mim. O exo-utils também é exigido por muitos pacotes, incluindo o pacote xfdesktop4, por isso é bastante difícil de remover: sudo dpkg -r --ignore-depende = xfce4-terminal, thunar-volman, squeeze, thunar, xfce4-panel, xfce4-verve -plugin, xfdesktop4 exo-utils
Peter Jenkins

1

Na guia "Visualizar" em "Editar -> Preferências", tente alternar todas as opções para "Nunca".

Também me ajudou enormemente a desativar as "Tecnologias Assistivas". Você pode fazer isso em "Sistema -> Preferências -> Tecnologias Assistivas". Desmarque a opção "Ativar tecnologias de assistência".

Você precisará sair e fazer login novamente para que a última alteração entre em vigor.


1
Hora de abrir uma pasta grande reduzida de cerca de 30 segundos para talvez dois segundos. Bom sofrimento.
wsmart

Minha postagem foi excluída aqui por outro usuário. pelo visto. Queria agradecer a Jay por seu post, pois fez uma enorme diferença no meu lento número de Nautius. Seja real, fique sóbrio.
wsmart
Ao utilizar nosso site, você reconhece que leu e compreendeu nossa Política de Cookies e nossa Política de Privacidade.
Licensed under cc by-sa 3.0 with attribution required.