Hızlı terminaller hakkında yanıldıklarım

• Hızlı bir kabuk yapılandırması yalnızca en aza indirilmiş ayarlarla elde edilmez; modern Zsh araçları algılanan başlangıç hızını farklı şekillerde iyileştirir
• time zsh -i -c exit, başlatma ve çıkış süresini birlikte ölçer; ancak kullanıcının gerçekten beklediği noktalar ilk prompt, ilk komutun çalışması ve giriş gecikmesidir
• zsh-bench, ilk prompt süresi, ilk komutun çalışmasına kadar geçen süre, komut gecikmesi ve giriş gecikmesi gibi gerçekten hissedilen unsurları ölçer
• Eklenti yöneticileri her zaman yavaş değildir; antidote, eklenti listesini tek bir statik betiğe derler ve başlangıçta bağımlılık çözümlemesi yapmaz
• Minimum yapılandırma, hızlı olmanın tek yolu değil; anlaşılabilir sadelik için yapılan bir tercihtir ve özellikli bir kabuk da anında tepki veriyormuş gibi hissedilebilir

---

Yanlış ölçtüğüm şey

• time zsh -i -c exit, etkileşimli kabuğu başlattıktan hemen sonra kapatan bir yöntemdir ve toplam başlatma ile çıkış süresini birlikte ölçer
• Bu yöntem yaygın kullanılan bir kıyaslama olsa da, zsh-bench bunun neden yanlış olduğunu ayrı bir bölümde ele alır
• Kullanıcının gerçekten beklediği şey toplam başlatma süresi değil; prompt’un görünmesi, ilk komutun çalışması ve sonrasındaki her tuş vuruşunun gecikmesidir
• Bazı yapılandırmalar bu kıyaslamada yavaş görünebilir ama gerçek kullanımda daha hızlı hissettirebilir
• zsh-bench, ilk prompt süresi, ilk komutun çalışmasına kadar geçen süre, komut gecikmesi ve giriş gecikmesini ölçer
• instant prompt, kabuk başlar başlamaz önbelleğe alınmış prompt’u render eder ve .zshrc tamamlanmadan önce bile girişe izin verir
• instant prompt kullanıldığında, başlatma maliyetinden bağımsız olarak algılanan açılış süresi neredeyse 0’a yaklaşır; bu da çıkış süresi sayısının önemini azaltır

Eklenti yöneticileri ve sözdizimi vurgulama hakkında düzeltme

• “Eklenti yöneticileri ek yük getirir” ifadesinin kapsamı fazla genişti

  • Bazı eklenti yöneticileri, açılışta kendi ek yüklerini ve bağımlılık çözümlemelerini ekler
  • Ancak bu özelliği tüm eklenti yöneticileri kategorisine yaymak doğru değildi
  • antidote, eklentilerin basit bir listesini tek bir statik betiğe derler ve kabuk açılırken bağımlılık çözümlemesi yapmaz
  • antidote yaklaşımında yapı, elle yazılmış source satırları gibi üretilmiş tek bir dosyanın source edilmesidir
  • Daha doğru ayrım şu: Her başlangıçta eklentileri çözen ağır framework’ler yavaştır, modern statik bundle yöneticileri ise değildir
  • Modern statik bundle yöneticileri ayrıca güncelleme yönetimi de sunar; elle hazırlanmış kurulum betikleri ise bunu manuel olarak halleder

• Yavaş bir sözdizimi vurgulayıcı önermiştim

  • Giriş gecikmesini ele alan bir yapılandırmada zsh-syntax-highlighting için source satırı kullanmış olmam, geriye dönüp bakınca utandırıcı bir tercihti
  • zsh-syntax-highlighting, her tuş vuruşunda tüm tamponu yeniden vurgular; bu da uzun komut satırlarında tam olarak tuş başına gecikme yaratabilir
  • Zsh-patina, daha yeni bir yaklaşımdır ve uzun komutlar yazanlar için şu anda kullandığım araçtan daha iyi bir his verebilir

• Geriye kalan iddianın özü

  • Tüm .zshrc dosyasını tek seferde okuyabilmek, gerçekten tercih ettiğim kısımdır
  • Asıl nokta, kararları bir framework’ün vermemesi ve seçmediğiniz eklentilerin bulunmamasıdır
  • Bileşen sayısı az olduğu için, yavaş bir bölüm ortaya çıktığında onu bulmak daha kolaydır
  • Bu seçim, hızın kendisinden çok sadelik tercihidir; sadeliğin hıza dönüşmesi ise yan etkidir
  • Tüm özelliklere sahip bir kabuk da hızlı ve anlık tepkili hissettirebilir; bu hedefe ulaşmanın birden fazla yolu vardır
  • Minimum yapılandırmayı korumamın nedeni, hızlı olmanın tek yolu olması değil, onu anlamak istememdir

• Kapanış

  • Orijinal yazı, üst kısmında bu yazıya işaret eden bir notla birlikte korunuyor
  • Yapılandırma hâlâ dotfiles içinde ve sözdizimi vurgulayıcı da yerinde duruyor
  • Bazı ayarların daha yeni araçları kullanacak şekilde güncellenmesi planlanıyor

[GN⁺]

Lobste.rs görüşleri

• Topluluğun ve fikir alışverişinin gücünü gösteren güzel bir devam yazısı; interneti biraz daha insani hissettiriyor

• İlk tepki, hatayı kabul edip düzeltmenin mümkün olmasına şaşırmak oluyor
  Ciddi konuşmak gerekirse, çeşitli yeni shell'leri pek sevmediğim için ilk yazıyı pas geçmiştim ama bu yazı hoşuma gitti. ashin varsayılan geçmiş davranışı kullanım şeklime uymuyor ve fish gibi shell'lerde ilgilenmediğim UI özelliklerinin fazla olduğunu düşünüyorum
  Yine de otomatik prompt cache gibi görünen özellikler iyi duruyor. Kendim de canavar gibi prompt'lar yapıp onları özensizce cache'lemeyi denediğim için daha anlamlı geliyor

• Böyle yazılar hoşuma gidiyor. Daha fazla insan hatalarını ve sonradan yaptığı düzeltmeleri açıkça paylaşırsa internet biraz daha insani bir yer olur

  • Yazarı benim. Teşekkürler; özellikle ekibe örnek olmak için hata kabul etme konusunda bunu sürekli yapmaya çalışıyorum

• İlk yazıyı gördükten sonra zaten zshrc dosyamı optimize edip süreyi yarıya indirmiştim. Sonra biraz daha araştırırken zsh-bench de kullandım; o yazı optimizasyon için bir tetikleyici oldu

• Artık bakım yapılmıyor ama zsh4humans performans açısından son derece ileri düzey. Yapan kişi adeta bir Zsh dahisi gibi
  Ben kullanmıyorum, çünkü kontrolü elde tutmak istiyorum. Yine de anlayabildiğim yerlerde transient prompt gibi fikirleri alıp kullandım
  zsh-benchin de aynı yazarın projesi olduğunu bilmiyordum

  • İyi öneri. zsh4humans projesinde gerçekten cevher niteliğinde parçalar var gibi görünüyor, bakacağım

• Bu yazı sayesinde zsh-patina diye bir şeyi öğrendim
  Yıllardır zsh-fast-syntax-highlighting kullanıyorum ama bu yeni aracı da değerlendirmem gerekecek

• zsh-syntax-highlightingın her tuş vuruşunda tüm buffer'ı yeniden vurgulayıp gecikme yarattığı kısmının gerçekten fark edilip edilmediğini merak ediyorum
  Kod editörleri de temelde benzer bir şey yapıyor ama orada neredeyse hiç gecikme hissetmedim. Komut satırı, editörlerle kıyaslayınca “uzun” komutlarda bile genelde kısa kaldığı için bunun sorun yaratması bana şaşırtıcı geliyor
  Ama syntax highlighting düşündüğümden çok daha karmaşıksa, o zaman olabilir

• Bu yazıdan pek çok yeni püf noktası öğrendim. Şimdiye kadar yalnızca prompt'a giren verilerin yavaş backend'lerden gelmesini engellemek gibi basit düzeltmeler yapıyordum
  Burada çok daha ayrıntılı prompt optimizasyonu var ve günlük akışta sayısız terminal açıldığında bu küçük iyileştirmeler birikerek büyük etki yaratıyor