तेज़ टर्मिनल के बारे में मैं कहाँ गलत था

• तेज़ shell config सिर्फ़ minimal settings से हासिल नहीं होती; आधुनिक Zsh tools महसूस होने वाली startup speed को अलग तरीकों से बेहतर बनाते हैं
• time zsh -i -c exit initialization और exit time को साथ में मापता है, लेकिन उपयोगकर्ता वास्तव में पहला prompt, पहला command चलना, और input latency का इंतज़ार करता है
• zsh-bench पहला prompt आने का समय, पहला command चलने का समय, command latency, और input latency जैसे वास्तव में महसूस होने वाले पहलुओं को मापता है
• plugin manager हमेशा धीमा नहीं होता; antidote plugin list को एक single static script में compile करता है और startup पर dependency resolution नहीं करता
• minimal config तेज़ी का एकमात्र रास्ता नहीं, बल्कि समझ में आने वाली सरलता के लिए एक विकल्प है; पूरी सुविधाओं वाला shell भी तुरंत responsive महसूस हो सकता है

---

मैंने क्या गलत मापा

• time zsh -i -c exit interactive shell को शुरू करके तुरंत बंद करने का तरीका है, और यह कुल initialization time और exit time को साथ में मापता है
• यह तरीका आम benchmark है, लेकिन zsh-bench बताता है कि यह तरीका क्यों गलत है, इसके लिए एक अलग section भी है
• उपयोगकर्ता वास्तव में कुल initialization time का इंतज़ार नहीं करता, बल्कि prompt दिखने, पहला command चलने, और उसके बाद हर key input की latency का इंतज़ार करता है
• कुछ configs इस benchmark में धीमे दिख सकते हैं, लेकिन वास्तविक उपयोग में ज़्यादा तेज़ महसूस हो सकते हैं
• zsh-bench पहला prompt समय, पहले command के चलने तक का समय, command latency, और input latency को मापता है
• instant prompt shell शुरू होते ही cached prompt render करता है और .zshrc पूरा होने से पहले भी input की अनुमति देता है
• instant prompt लागू होने पर initialization cost चाहे जो हो, महसूस होने वाली startup speed लगभग 0 के करीब हो जाती है, इसलिए exit time का नंबर कम महत्वपूर्ण रह जाता है

plugin manager और syntax highlighting पर सुधार

• “plugin manager overhead बढ़ाते हैं” कहना बहुत व्यापक था

  • कुछ plugin managers startup पर अपना overhead और dependency resolution जोड़ते हैं
  • लेकिन इस गुण को पूरे plugin manager category पर लागू करना सही नहीं था
  • antidote plugins की एक simple list को एक single static script में compile करता है, और shell खोलते समय dependency resolution नहीं करता
  • antidote का तरीका ऐसा है कि generated file में सीधे source किया जाता है, ठीक वैसे जैसे आप खुद source lines लिखते हैं
  • ज़्यादा सही अंतर यह है कि हर startup पर plugins resolve करने वाले heavy frameworks धीमे होते हैं, जबकि modern static bundling managers नहीं
  • modern static bundling managers update management भी देते हैं, जबकि खुद की install scripts में यह काम manually करना पड़ता है

• मैंने एक धीमा syntax highlighter सुझाया था

  • input latency पर बात करने वाली config में zsh-syntax-highlighting को source करना, पीछे मुड़कर देखने पर शर्मनाक चुनाव लगता है
  • zsh-syntax-highlighting हर keypress पर पूरे buffer को फिर से highlight करता है, और लंबी command lines में यही per-keypress latency पैदा कर सकता है
  • Zsh-patina एक नया approach है, और लंबी commands टाइप करने पर यह मौजूदा tool से बेहतर अनुभव दे सकता है

• जो बात अब भी बचती है

  • पूरी .zshrc को एक बार में पढ़ पाने की बात ही वास्तव में पसंद की जाने वाली चीज़ है
  • अहम बात यह है कि framework आपके लिए फ़ैसले नहीं करता, और कोई ऐसा plugin नहीं है जिसे आपने चुना न हो
  • components कम होने से, अगर कुछ धीमा हो, तो उसे ढूँढना आसान होता है
  • यह चुनाव speed से ज़्यादा simplicity की पसंद है; simplicity का speed में बदल जाना एक side effect है
  • पूरी सुविधाओं वाला shell भी तेज़ और तुरंत responsive महसूस हो सकता है, और वहाँ तक पहुँचने के कई तरीके हैं
  • minimal config को इसलिए बनाए रखा जाता है कि वह तेज़ी का एकमात्र रास्ता नहीं, बल्कि इसलिए कि उसे समझना है

• समापन

  • मूल लेख ऊपर इस लेख की ओर इशारा करने वाले एक note के साथ वैसे ही रखा गया है
  • config अभी भी dotfiles में है, और syntax highlighter भी वहीं बना हुआ है
  • कुछ settings को बाद में अधिक आधुनिक tools इस्तेमाल करने के लिए update किया जाएगा

[GN⁺]

Lobste.rs की राय

• यह एक अच्छा फॉलो-अप लेख है जो कम्युनिटी और आइडिया के आदान-प्रदान की ताकत दिखाता है, और इंटरनेट को थोड़ा ज़्यादा मानवीय महसूस कराता है

• पहले तो इस बात पर हैरानी हुई कि गलती मानना और उसे सुधारना भी संभव है
  गंभीरता से कहूँ तो, मुझे कई नए shell खास पसंद नहीं हैं इसलिए पहला लेख छोड़ दिया था, लेकिन यह वाला अच्छा लगा। ash का डिफ़ॉल्ट history behavior मेरे इस्तेमाल के तरीके से मेल नहीं खाता, और fish जैसे shell में मुझे ऐसे UI features ज़रूरत से ज़्यादा लगे जिनमें मेरी दिलचस्पी नहीं है
  हालांकि, automatic prompt cache जैसी दिखने वाली सुविधा अच्छी लगी। मैंने खुद भी कभी बहुत भारी-भरकम prompt बनाया था और उसे ढीले-ढाले तरीके से cache किया था, इसलिए यह बात ज़्यादा समझ आई

• ऐसे लेख अच्छे लगते हैं। अगर ज़्यादा लोग अपनी गलतियाँ और बाद की सुधार-सूचनाएँ सार्वजनिक करें, तो इंटरनेट थोड़ा और मानवीय स्थान बनेगा

  • मैं लेखक हूँ। धन्यवाद, और खास तौर पर टीम के लिए उदाहरण पेश करने के लिए गलती स्वीकार करने की आदत लगातार बनाए रखने की कोशिश करता हूँ

• पहला लेख देखकर मैंने पहले ही अपना zshrc optimize कर लिया था और समय आधा कर दिया। बाद में और खोजते हुए zsh-bench भी इस्तेमाल किया, और वह लेख optimization का ट्रिगर बन गया

• अब इसका maintenance नहीं हो रहा, लेकिन zsh4humans performance के लिहाज़ से लगभग cutting edge है। इसे बनाने वाला व्यक्ति किसी तरह का Zsh जीनियस लगता है
  मैं इसे खुद इस्तेमाल नहीं करता, क्योंकि मैं control अपने पास रखना चाहता हूँ। फिर भी जहाँ समझ सका, वहाँ से transient prompt जैसी ideas लेकर इस्तेमाल कीं
  मुझे यह नहीं पता था कि zsh-bench भी उसी लेखक का प्रोजेक्ट है

  • बढ़िया टिप है। zsh4humans प्रोजेक्ट में सचमुच कुछ रत्न जैसे हिस्से लग रहे हैं, इसलिए मैं इसे ज़रूर देखूँगा

• इस लेख की वजह से मुझे zsh-patina के बारे में पता चला
  मैं कई सालों से zsh-fast-syntax-highlighting इस्तेमाल कर रहा हूँ, लेकिन इस नए टूल का भी मूल्यांकन करना पड़ेगा

• zsh-syntax-highlighting हर key input पर पूरे buffer को फिर से highlight करके latency पैदा करता है—क्या यह सच में ध्यान देने लायक स्तर पर दिखता है, यह जानने की जिज्ञासा है
  code editor भी मूल रूप से कुछ ऐसा ही करते हैं, लेकिन वहाँ latency शायद ही महसूस होती है। command line, editor के हिसाब से देखें तो “लंबे” command भी आम तौर पर छोटे ही होते हैं, इसलिए यहाँ समस्या होना थोड़ा अप्रत्याशित लगता है
  हाँ, अगर syntax highlighting सोचे से कहीं ज़्यादा जटिल हो, तो बात अलग हो सकती है

• इस लेख से मैंने कई नई तरकीबें सीखीं। अब तक मैं बस इतने भर के साधारण सुधार करता था कि prompt में आने वाला data धीमे backend से न आए
  यहाँ इससे कहीं ज़्यादा बारीक prompt optimization है, और रोज़मर्रा के उस workflow में जहाँ terminal अनगिनत बार खुलता है, ऐसे छोटे सुधार जुड़कर बड़ा असर डालते हैं