Editores Nano / VIM não usam recursos

Question

Alguém aqui conhece os recursos necessários para os editores pesquisarem e substituirem em um arquivo grande? A razão pela qual estou perguntando é se eu tenho um servidor núcleo de 32 que HTOP está exibindo apenas um núcleo a 100% ao pesquisar / substituir em um arquivo de 3 GB com um editor. Eu estou querendo saber se o meu editor de pesquisa / substituição é um único thread, e se assim houver uma maneira de delegar mais recursos para que essas tarefas não demorem tanto? Eu tenho que dizer, é frustrante ver 31 núcleos inativos e 1 a 100% quando uma tarefa leva de 25 a 30 minutos.

Ah, e se isso faz diferença, a RAM é de 32 GB, com 19 GB usados, incluindo cache.

    

Answer 1

Um editor pode ou não ser multiencadeado, mas, mesmo que seja, é improvável que ele use encadeamentos para essa finalidade por uma simples razão: isso não forneceria nenhuma vantagem para uso normativo , e sem dúvida criaria dores de cabeça do desenvolvedor e, possivelmente, comprometimento de recursos que são considerados importantes (para uso normativo).

Dado uma quantidade infinita de tempo e um número infinito de programadores, sem dúvida todo software seria descontroladamente otimizado até os menores detalhes irrelevantes, extensivamente testados para garantir que essas otimizações não causassem impacto negativo em nada, etc. alguém quer gastar seu tempo codificando recursos 99,9% dos usuários nunca irão apreciar, especialmente se os 0,1% que fazem isso porque, por exemplo, (uma analogia) eles realmente queriam abrir latas de sopa com um martelo.

Como algumas pessoas apontaram, carregar um arquivo de 3 GB em um editor de texto para fazer uma pesquisa e uma substituição é bom, algo que você faria se a maneira única que você soubesse fazer pesquisar e substituir está em um editor de texto. Eu não estou tentando te insultar com isso, BTW, apenas dar-lhe uma cutucada amigável - agora é a hora de ampliar alguns horizontes;)

    

Answer 2

O mais provável é que os editores tenham um único thread. Você provavelmente seria melhor dividir seu arquivo em 32 partes e usar algo como perl ou sed para pesquisar e substituir.

    

Answer 3

Confira sed , o editor de fluxo. Ele tem um conjunto de comandos parecido com vi , mas não lê o arquivo para processá-lo, lê, modifica e escreve uma linha de cada vez (principalmente, veja o manual). Assim, você pode pelo menos reduzir o tempo necessário para ler o arquivo (o editor tem que construir estruturas complexas de dados na memória) e depois escrevê-lo.

[Eu estou (não tão) surpreso que o lote atual de editores é capaz de processar tais arquivos, eu me lembro com carinho que o original vi caiu mal com arquivos que tinham algumas dezenas de KiB em tamanho ... sic transit gloria mundii.]

    

Answer 4

Pesquisar e substituir mais de 3 GB de texto é uma tarefa difícil para qualquer editor. A melhor solução, na minha opinião, é usar Perl . Você pode usar perl para dividir automaticamente o arquivo em partes menores e executar o regex em paralelo em cada parte. Há muita maneira de codificar isso em perl. Vou postar um exemplo depois.