"Editörüm yavaş" şikâyeti çoğu zaman belirsiz bir hisle konuşulur; oysa açılış süresi ölçülebilir, profil çıkarılabilir ve cerrahi hassasiyetle onarılabilir bir veridir. Her sabah üç saniye kaybeden bir geliştirici, yıllık izin günü kadar zamanı profil çıktısının içinde saklar. Bu yazı, ölçümden onarıma giden yolu adım adım izliyor: önce sürenin nereye gittiğini bulacağız, sonra suçluyu işaret edip kibri küçülteceğiz.

Önce ölç: milisaniyelerin adresi

Vim ailesinde açılış süresinin dağılımı tek komutta saklıdır. Çıktı, eklentiler ve yapılandırma satırlarının her birinin açılışa ne kadar eklediğini milisaniye cinsinden sıralar:

# Vim: acilis suresini kaynak sirasiyla raporla
vim --startuptime /tmp/vim-start.log +qa && tail -20 /tmp/vim-start.log

# Neovim ayni isi gorsel zaman cizelgesiyle yapar
nvim --startuptime /tmp/nvim-start.log +qa

VS Code tarafında süreç görsel: Komut paletinden "Startup Performance" çalıştırdığınızda her eklentinin etkinleştirilme süresi tablo hâlinde çıkar. JetBrains'te ise Help menüsündeki etkinlik izleyicisi eklenti yüklenmelerini saniyelerle raporlar. Hangi editör olursa olsun ilke aynıdır: hissi değil, milisaniyeleri konuş. Ölçümü karşılaştırılabilir tutmak için de aynı koşullarda yapın: aynı makine, aynı eklenti seti, benzer dosya büyüklüğü; iki farklı ölçüm koşulunu kıyaslamak, yanlış suçluya yönlendirir.

Suçluyu bulmak

Profil çıktısında kalıp tekrarlar: toplam sürenin yarısına sahip üç eklenti. Yaygın sanıklar arasında ağ çağrısı yapan eklentiler (sürüm denetleyicisi, hava durumu, güncelleme kontrolü), açılışta tüm dosya ağacını tarayan dil sunucuları ve çok büyük bir renk teması dosyası sayılabilir. Ayrıca yapılandırma içindeki döngüler ve "her şeyi yükle" tarzı mega konfigürasyonlar sessiz kalır ama faturayı büyütür. Kopyala-yapıştır yapılandırmalarda bu tablo klasiktir: üç yıl önce bir blog yazısından alınan satırlar, artık kurulmayan eklentileri her açılışta arar ve boşuna zaman öder.

# Ornek profil okumasi
003.2  plugins/lsp-config.lua      -> acilista ag cagrisi yapma
002.8  plugins/treesitter.lua      -> dil bilgisini ertele
001.9  after/syntax/large-file.vim -> buyuk dosya kurallarini gec yukle

Okuma taktiği basittir: en büyük üç satırı işaretleyin, toplamın yüzde kaçını açıkladıklarına bakın. Pareto burada da geçerlidir; on eklentinin dokuzu değil, üçü süreyi belirler. Suçluyu bulmak için ayrıca ikili karşılaştırma yapabilirsiniz: yapılandırmayı boş bir dizinle (vim -u NONE) açıp ölçümü tekrarlayın; aradaki fark, yapılandırmanızın toplam bedelidir.

Onarım: erken yükleme yerine geç yükleme

Cerrahinin cümlesi ortaktır: kritik olmayan her şeyi açılıştan sonra yükle. Eklenti yöneticilerinin çoğu gecikmeli yükleme desteği sunar; eklentiyi ilk kullanım anına ya da belirli dosya tipine kadar erteleyin. Ağ çağrılarını açılıştan sonraki ilk boş tıklamaya taşıyın, dil sunucusunu ilk dosya açılışında başlatın. Vim'de autocmd ile tetiklenen yükleme aynı işi yapar:

"treesitter i ilk dosya acilisinda yukle
autocmd BufRead * packadd nvim-treesitter | call init#treesitter()

Ölçümü de alışkanlık hâline getirin: büyük bir eklenti güncellemesinden sonra aynı komutu çalıştırmak, regresyonu ilk gün yakalar. Onarımdan sonra beklenmedik bir yan etki görürseniz — boş bir durum çubuğu, geç yüklenen bir renk şeması — geri alın ve ertelemeyi parça parça yapın; tek seferde on eklentiyi ertelemek, hangisinin sorunu çıkardığını bulamazsınız. Cerrahide olduğu gibi küçük ve kontrollü kesiler en iyisidir.

Profil çıktısını okumak, editör ayarı ile ilgili mitleri de bitirir: gerçek suçlu genellikle sanılandan farklıdır ve el yordamı yerine veriye bakmak, "sanki yavaşladı" tartışmasını bir kez için sonlandırır. Ayda bir tekrarlanan beş dakikalık profil, editörünüzün hızını bir donanım yükseltmesinden daha kalıcı korur.