Mover minha pasta pessoal para uma unidade que não seja de inicialização diminui o desempenho?


5

Vou obter um SSD, tornando essa a minha unidade de inicialização e movendo o disco rígido existente para o compartimento da unidade óptica. Vou manter meus dados no disco rígido original.

O MacPerformanceGuide.com diz "Se a unidade de inicialização for um SSD rápido, mover o diretório inicial pode ser prejudicial para o desempenho".

Deixe-me ser claro. Estou falando especificamente do diretório inicial . O MacPerformanceGuide fala sobre a importância de mover as pastas Documentos, biblioteca do iTunes etc., mas não a pasta inicial.

Por que é que?

Estamos não falar sobre vestindo o SSD com ciclos de escrita excessivos; estamos falando de desempenho.


Alguns mais informações sobre como fazer o máximo proveito se o seu SSD: apple.stackexchange.com/a/25237/10355

Respostas:


2

O OS X armazena uma quantidade considerável de dados, de caches de programa a uma infinidade de preferências e outros arquivos tmp vitais, na sua pasta pessoal (Biblioteca para ser mais preciso). Mudar isso do SSD é prejudicial. O sistema ainda extrairia arquivos do seu SSD veloz, mas todos os arquivos de cache dos seus aplicativos (de terceiros e padrão) seriam extraídos do HDD tradicional e complicado.

É recomendável descarregar arquivos grandes e estáticos, como músicas, filmes, livros e outros documentos que se beneficiam pouco da velocidade de um SSD. Mas mover pequenos arquivos principais que se beneficiam muito de discos de estado sólido não é. É crucial manter o maior número possível de componentes integrais do sistema em seu SSD. Um filme de 2 GB ou 1.000 músicas não será beneficiado porque os filmes não precisam ser reproduzidos mais rapidamente, nem as músicas. Eles podem carregar um pouco mais rápido e, no futuro, quando os SSDs tiverem TB de espaço, isso não será mais um problema, mas, por enquanto, trata-se de triagem.

Suponho que você possa tentar microgerenciar esse aspecto, mas, para ser 100% seguro, eu apenas moveria os itens mais caros. Um SSD de 120 GB com 5 GB não será mais rápido do que um com 20 GB.


Mudar os arquivos tmp do SSD para algo mais lento é apenas prejudicial para esses arquivos tmp. Para arquivos fora da pasta base, o desempenho é aprimorado movendo a pasta base para outra unidade. Além disso, qualquer disco rígido (incluindo SSDs) será significativamente mais rápido se não tiver sido muito usado e estiver quase vazio. Todo o uso da unidade "suja" a estrutura de dados interna e a torna mais lenta. Basicamente, depende de como o @radarbob usa seu sistema.
Abhi Beckert

"qualquer disco rígido (incluindo SSDs) [ênfase meu] será significativamente mais rápido se não tiver sido muito usado e estiver quase vazio." Este artigo do MacPerformance diz o contrário. Mostrando graficamente que a E / S SSD é plana, onde um inversor mecânico, depois de cerca de 50% cheio, começa a perder desempenho em até 30%, à medida que fica saturado.
Radarbob

0

Porque você estará constantemente na área de trabalho e na biblioteca quando abrir / fechar programas.

Se eles estiverem no HD normal, eles lerão / gravarão na velocidade normal do HD.


0

Não concordo com a resposta aceita na prática.

É claro que, se você colocar alguns arquivos em um armazenamento mais lento que o SSD, terá claramente tempos de acesso mais lentos para esses arquivos, mas a velocidade no uso real do OS X 10.7 e posterior - a grande maioria dos ganhos de velocidade advém do SSD fazendo o backup do SSD. SO e os aplicativos e as bibliotecas e caches do sistema.

A natureza da E / S serial de arquivo grande é que, quando você está lendo ou gravando em filmes, vídeos, arquivos de imagem fotográfica e outros itens - o HDD realmente funciona muito bem e o sistema sabe como otimizar e aguardar que a E / S serial seja concluída sem bloquear o usuário . Da mesma forma, os buffers de leitura antecipada são ótimos para gerenciar padrões de acesso conhecidos / previsíveis.

O SSD se destaca em outras áreas e desde que você não tenha um sistema que esteja sob enorme pressão de memória RAM - você pode executar com todos os arquivos de usuário no HDD e o restante dos arquivos no SSD com bastante satisfação e realizar grandes acelerações ao ter todos os arquivos no disco rígido.

Algumas exceções à regra geral seriam o armazenamento da Máquina Virtual - pode valer a pena copiá-las do HDD para o SSD se você tiver espaço para executar uma VM a partir do SSD.

Eu tenho alguns sistemas nos quais há quase um total de imagens de VM de TB, mas eu só preciso de 100 GB de VM em execução ao mesmo tempo e moverei as imagens para o SSD antes de iniciar o software hypervisor quando o benefício de desempenho para esse uso me merece atenção sobre onde arquivos específicos estão armazenados.


-2

Em geral, dividir seus dados entre várias unidades sempre melhorará o desempenho. Em um mundo ideal, todos os arquivos em seu sistema estariam em seu próprio disco rígido com seu próprio cache de disco / etc.

Mas apenas se a outra unidade for pelo menos tão rápida quanto a que você a remove. Se você substituir uma unidade interna por uma unidade USB ou até mesmo um raio, o desempenho provavelmente será reduzido.

Se sua unidade de inicialização interna for um SSD de ponta e você mover o diretório inicial para um cartão de memória USB de US $ 3, o desempenho será uma porcaria. Por outro lado, se você mover o diretório inicial para um segundo SSD interno, melhorará o desempenho em várias situações.

Para algo entre os dois, você terá que usar seu próprio julgamento e / ou testá-lo. A resposta vai depender exatamente para o que você usa seu disco rígido. Sem saber exatamente a rapidez com que o seu SSD e os discos rígidos existentes são, ou como você usa o sistema, é difícil prever qual será a melhor solução.


-1 para "Em um mundo ideal, todo arquivo ... em seu próprio disco rígido .." Não é útil. Além disso, "... mude..para um segundo SSD interno ... melhorará o desempenho ..." - não nega a premissa de que a pasta inicial em uma unidade que não seja de inicialização não tem o desempenho ideal.
Radarbob 17/03/12
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.