Desempenho e tempo de inicialização

    Definição curta: Uma configuração bem organizada inicia em menos de 100 ms mesmo com dezenas de plugins; quando não inicia, há sempre um culpado identificável.

    Antes de começar

    • Neovim v0.11 ou mais recente instalado — confira com nvim --version
    • Um init.lua que já carrega, ainda que vazio

    O que você vai aprender

    • Explicar Medir antes de otimizar com suas palavras
    • Explicar Onde o tempo costuma ir com suas palavras
    • Explicar Arquivos grandes com suas palavras
    • Localizar o assunto desta página no :help do seu próprio Neovim

    Medir antes de otimizar

    Três ferramentas, da mais grossa para a mais fina:

    nvim --startuptime /tmp/start.log +q && tail -20 /tmp/start.log

    O arquivo lista cada etapa com o tempo acumulado. A última linha é o total. Valores de referência: abaixo de 100 ms é bom, acima de 300 ms incomoda, acima de 1 s costuma indicar um plugin carregado sem necessidade.

    :Lazy profile

    Se você usa lazy.nvim, este é o diagnóstico mais direto — ele mostra o tempo por plugin e separa o que é carregamento do que é configuração.

    nvim --clean

    Inicia sem nenhuma configuração. Se o problema desaparece, é a sua config; se persiste, é o Neovim, o terminal ou o sistema de arquivos.

    Onde o tempo costuma ir

    Plugins carregados sem necessidade. O maior ganho, quase sempre. Um plugin de git que carrega na inicialização em vez de no primeiro uso custa dezenas de milissegundos.

    Providers não usados. O Neovim procura interpretadores de Python, Ruby, Perl e Node na inicialização. Se você não usa nenhum:

    vim.g.loaded_python3_provider = 0
vim.g.loaded_ruby_provider = 0
vim.g.loaded_perl_provider = 0
vim.g.loaded_node_provider = 0

    Plugins internos do Vim que você não usa.

    vim.g.loaded_netrwPlugin = 1     -- se usa outro explorador de arquivos
vim.g.loaded_gzip = 1
vim.g.loaded_tarPlugin = 1
vim.g.loaded_zipPlugin = 1

    shada grande. O arquivo de estado acumula histórico. Se estiver enorme, reduza o que é guardado:

    vim.opt.shada = "'100,<50,s10,h"

    Arquivos grandes

    O tempo de inicialização é um problema; a lentidão ao editar um arquivo de 50 mil linhas é outro. Os culpados usuais:

    • Treesitter reanalisando a cada tecla
    • LSP enviando o buffer inteiro a cada mudança
    • cursorline e relativenumber forçando redesenho
    • Expressões complexas em foldexpr ou statuscolumn

    Uma solução comum é desligar seletivamente para arquivos acima de um limite:

    vim.api.nvim_create_autocmd('BufReadPre', {
  callback = function(args)
    local ok, stats = pcall(vim.uv.fs_stat, vim.api.nvim_buf_get_name(args.buf))
    if ok and stats and stats.size > 1024 * 1024 then   -- 1 MB
      vim.b[args.buf].large_file = true
      vim.opt_local.foldmethod = 'manual'
      vim.opt_local.spell = false
      vim.opt_local.cursorline = false
      vim.cmd('syntax off')
    end
  end,
})

    Opções que ajudam

    vim.opt.lazyredraw = true    -- não redesenha durante macros
vim.opt.updatetime = 250     -- resposta de CursorHold; padrão 4000 é lento demais
vim.opt.timeoutlen = 300     -- espera por sequências de teclas
vim.opt.synmaxcol = 240      -- limita realce em linhas muito longas

    Cuidado com lazyredraw: ele acelera macros e pode causar artefatos visuais com alguns plugins de interface.

    O terminal também conta

    Nem toda lentidão é do Neovim. Terminais com renderização por software ficam lentos com muita cor e ligaduras. Testar a mesma config em outro emulador é um diagnóstico barato antes de mexer em qualquer coisa.

    Verifique também se termguicolors está ligado e se o terminal de fato suporta cor de 24 bits:

    vim.opt.termguicolors = true

    Uma rotina de diagnóstico

    1. nvim --startuptime — qual é o total?
    2. Se alto: :Lazy profile — qual plugin domina?
    3. nvim --clean — o problema é da config?
    4. Se a lentidão é ao editar, não ao iniciar: :e um arquivo pequeno e comparar
    5. :checkhealth — ver solução de problemas

    Erros comuns

    • Otimizar sem medir — quase sempre se corta o plugin errado
    • Culpar o Neovim por lentidão que é do terminal ou do sistema de arquivos
    • Desligar Treesitter globalmente por causa de um arquivo grande
    • updatetime muito baixo (abaixo de 100) — dispara autocommands demais
    • Confundir tempo de inicialização com tempo até a interface aparecer — o segundo é o que você percebe

    Você aprendeu

    • Medir antes de otimizar
    • Onde o tempo costuma ir
    • Arquivos grandes
    • Opções que ajudam
    • O terminal também conta

    Perguntas para reflexão

    1. O que Medir antes de otimizar resolve, e o que se perde sem isso?
    2. O que Onde o tempo costuma ir resolve, e o que se perde sem isso?
    3. O que Arquivos grandes resolve, e o que se perde sem isso?
    4. Qual parte desta página você conseguiria reproduzir sem consultar, direto no editor?

    Artigos relacionados

    Veja também

    Referências

    • :help startuptime
    • :help --clean
    • :help provider