สิ่งที่ฉันเคยเข้าใจผิดเกี่ยวกับเทอร์มินัลที่รวดเร็ว

 (mijndertstuij.nl)
1 คะแนน โดย GN⁺ 5 시간 전 | 1 ความคิดเห็น | แชร์ทาง WhatsApp
  • การตั้งค่าเชลล์ให้เร็วไม่ได้เกิดขึ้นจากการมีคอนฟิกให้น้อยที่สุดเท่านั้น และเครื่องมือ Zsh ยุคใหม่ก็ปรับปรุง ความเร็วในการเริ่มต้นที่ผู้ใช้รู้สึกได้ ด้วยวิธีอื่น
  • time zsh -i -c exit วัดทั้งเวลาเริ่มต้นและเวลาปิด แต่จุดที่ผู้ใช้รอจริง ๆ คือ พรอมต์แรก, การรันคำสั่งแรก และความหน่วงของการพิมพ์
  • zsh-bench วัดสิ่งที่ผู้ใช้รู้สึกได้จริง เช่น เวลาถึงพรอมต์แรก เวลาถึงการรันคำสั่งแรก ความหน่วงของคำสั่ง และความหน่วงของการพิมพ์
  • ตัวจัดการปลั๊กอินไม่ได้ช้าเสมอไป โดย antidote จะคอมไพล์รายการปลั๊กอินเป็นสคริปต์สแตติกไฟล์เดียว จึงไม่ต้องแก้การพึ่งพาตอนเริ่มต้น
  • การตั้งค่าแบบมินิมัลไม่ใช่หนทางเดียวสู่ความเร็ว แต่เป็นทางเลือกเพื่อ ความเรียบง่ายที่เข้าใจได้ และเชลล์ที่มีฟีเจอร์ครบก็อาจให้ความรู้สึกตอบสนองฉับไวได้เช่นกัน

สิ่งที่วัดผิด

  • time zsh -i -c exit เป็นวิธีที่เริ่มเชลล์แบบโต้ตอบแล้วปิดทันที ซึ่งวัดทั้งเวลาเริ่มต้นทั้งหมดและเวลาปิดรวมกัน
  • วิธีนี้เป็นเบนช์มาร์กที่ใช้กันบ่อย แต่ zsh-bench มีส่วนแยกต่างหากที่อธิบายว่าทำไมวิธีนี้จึงไม่ถูกต้อง
  • สิ่งที่ผู้ใช้รอจริง ๆ ไม่ใช่เวลาเริ่มต้นทั้งหมด แต่คือการแสดงพรอมต์ การรันคำสั่งแรก และความหน่วงของทุกการกดแป้นหลังจากนั้น
  • คอนฟิกบางแบบอาจดูช้าในเบนช์มาร์กนี้ แต่ในการใช้งานจริงอาจรู้สึกเร็วกว่า
  • zsh-bench วัดเวลาถึงพรอมต์แรก เวลาถึงการรันคำสั่งแรก ความหน่วงของคำสั่ง และความหน่วงของการพิมพ์
  • instant prompt จะแสดงพรอมต์ที่แคชไว้ทันทีที่เชลล์เริ่ม และยังพิมพ์ได้แม้ .zshrc จะยังโหลดไม่เสร็จ
  • เมื่อใช้ instant prompt เวลาเริ่มต้นที่ผู้ใช้รู้สึกได้จะใกล้ 0 มากแทบไม่ขึ้นกับต้นทุนการเริ่มต้น ทำให้ตัวเลขเวลาในการปิดมีความสำคัญน้อยลง

คำชี้แจงเกี่ยวกับตัวจัดการปลั๊กอินและการไฮไลต์ไวยากรณ์

  • ประโยคที่ว่า “ตัวจัดการปลั๊กอินเพิ่มโอเวอร์เฮด” กว้างเกินไป

    • ตัวจัดการปลั๊กอินบางตัวเพิ่มโอเวอร์เฮดของตัวเองและมีการแก้การพึ่งพาในตอนเริ่มต้น
    • แต่การนำคุณลักษณะนี้ไปเหมารวมกับตัวจัดการปลั๊กอินทั้งหมดนั้นไม่แม่นยำ
    • antidote จะคอมไพล์รายการปลั๊กอินแบบเรียบง่ายให้เป็นสคริปต์สแตติกไฟล์เดียว และไม่แก้การพึ่งพาเมื่อเปิดเชลล์
    • แนวทางของ antidote คือ source ไฟล์ที่สร้างขึ้นมาเพียงไฟล์เดียว คล้ายกับการเขียนบรรทัด source เอง
    • การแยกแยะที่แม่นยำกว่าคือ เฟรมเวิร์กหนัก ๆ ที่ตีความปลั๊กอินทุกครั้งตอนเริ่มต้นนั้นช้า แต่ตัวจัดการแบบ static bundling สมัยใหม่ไม่เป็นเช่นนั้น
    • ตัวจัดการแบบ static bundling สมัยใหม่ยังมีระบบจัดการอัปเดตให้ด้วย ขณะที่สคริปต์ติดตั้งที่ทำเองต้องจัดการส่วนนี้ด้วยมือ

  • ฉันเคยแนะนำตัวไฮไลต์ไวยากรณ์ที่ช้า

    • เมื่อนึกย้อนกลับไป การ source zsh-syntax-highlighting ในคอนฟิกที่พูดถึงความหน่วงของการพิมพ์ถือเป็นตัวเลือกที่น่าอาย
    • zsh-syntax-highlighting จะไฮไลต์บัฟเฟอร์ทั้งหมดใหม่ทุกครั้งที่กดแป้น และในบรรทัดคำสั่งยาว ๆ ก็อาจทำให้เกิดความหน่วงรายคีย์แบบที่กำลังพูดถึงนี่เอง
    • Zsh-patina เป็นแนวทางที่ใหม่กว่า และหากต้องพิมพ์คำสั่งยาว ๆ ก็อาจให้ความรู้สึกที่ดีกว่าเครื่องมือที่ใช้อยู่ตอนนี้

  • แก่นของข้อสรุปที่ยังคงอยู่

    • สิ่งที่ชอบจริง ๆ คือการสามารถอ่าน .zshrc ทั้งไฟล์ได้ในคราวเดียว
    • ประเด็นสำคัญคือเฟรมเวิร์กไม่ได้เป็นฝ่ายตัดสินใจแทน และไม่มีปลั๊กอินที่ไม่ได้เลือกติดมาด้วย
    • เพราะมีองค์ประกอบน้อยกว่า ถ้าเกิดจุดช้าก็หาได้ง่ายกว่า
    • ทางเลือกนี้สะท้อนความชอบในความเรียบง่ายมากกว่าความเร็วโดยตรง และความเรียบง่ายที่นำไปสู่ความเร็วนั้นเป็นผลพลอยได้
    • เชลล์ที่มีฟีเจอร์ครบก็สามารถเร็วและให้ความรู้สึกตอบสนองทันทีได้เช่นกัน และมีหลายวิธีที่จะไปถึงเป้าหมายนั้น
    • การคงการตั้งค่าแบบมินิมัลไว้ไม่ใช่เพราะมันเป็นหนทางเดียวสู่ความเร็ว แต่เพราะอยากเข้าใจมัน

  • ปิดท้าย

    • บทความต้นฉบับยังคงอยู่โดยมีบันทึกด้านบนที่ชี้มายังบทความนี้
    • คอนฟิกยังอยู่ใน dotfiles และตัวไฮไลต์ไวยากรณ์ก็ยังคงอยู่เช่นเดิม
    • การตั้งค่าบางส่วนจะถูกอัปเดตให้ใช้เครื่องมือที่ใหม่กว่านี้

บทความที่เกี่ยวข้อง

1 ความคิดเห็น

 
GN⁺ 5 시간 전
ความคิดเห็นจาก Lobste.rs

  • เป็นบทความติดตามผลที่ดี แสดงให้เห็นพลังของชุมชนและการแลกเปลี่ยนไอเดีย ทำให้อินเทอร์เน็ตรู้สึกมีความเป็นมนุษย์ขึ้นอีกนิด

  • ปฏิกิริยาแรกคือแปลกใจที่ยังมีคนยอมรับและแก้ไขข้อผิดพลาดได้จริง
    เอาจริง ๆ แล้วฉันไม่ค่อยชอบเชลล์ใหม่ ๆ เลยข้ามบทความแรกไป แต่บทความนี้ชอบมาก ash มีพฤติกรรม history เริ่มต้นที่ไม่เข้ากับวิธีใช้งานของฉัน และเชลล์อย่าง fish ก็รู้สึกว่ามีฟีเจอร์ UI ที่เยอะเกินไปในส่วนที่ฉันไม่สนใจ
    แต่ฟีเจอร์ที่ดูเหมือน prompt cache อัตโนมัตินั้นน่าสนใจ เคยทำ prompt สัตว์ประหลาดเองและแคชแบบลวก ๆ มาก่อน เลยอินเป็นพิเศษ

  • ชอบบทความแบบนี้ ถ้ามีคนเปิดเผยความผิดพลาดและการแก้ไขติดตามผลมากขึ้น อินเทอร์เน็ตก็จะเป็นพื้นที่ที่มีความเป็นมนุษย์มากขึ้นอีกหน่อย

    • ผู้เขียนเอง ขอบคุณมาก และพยายามยอมรับ ความผิดพลาด อย่างสม่ำเสมอ โดยเฉพาะเพื่อเป็นตัวอย่างให้ทีม

  • หลังจากอ่านบทความแรกก็ไปปรับแต่ง zshrc แล้ว ลดเวลาได้ครึ่งหนึ่ง จากนั้นก็หาข้อมูลต่อและได้ใช้ zsh-bench ด้วย ดังนั้นบทความนั้นจึงกลายเป็น จุดเริ่มต้นของการปรับแต่งประสิทธิภาพ

  • แม้จะไม่ได้รับการดูแลต่อแล้ว แต่ zsh4humans ก็ยังใกล้เคียงระดับล้ำหน้าสุดในแง่ประสิทธิภาพ คนสร้างดูเหมือนเป็น อัจฉริยะด้าน Zsh อยู่เหมือนกัน
    ฉันไม่ได้ใช้เอง เพราะอยากคงการควบคุมไว้ แต่ก็หยิบแนวคิดบางอย่างที่เข้าใจได้มาใช้ เช่น transient prompt
    ไม่รู้มาก่อนว่า zsh-bench ก็เป็นโปรเจกต์ของผู้เขียนคนเดียวกัน

    • เป็นทิปที่ดีมาก ดูเหมือนในโปรเจกต์ zsh4humans จะมีของดีซ่อนอยู่จริง ๆ เดี๋ยวจะไปดู

  • บทความนี้ทำให้ได้รู้จัก zsh-patina
    ใช้ zsh-fast-syntax-highlighting มาหลายปีแล้ว แต่เครื่องมือตัวใหม่นี้ก็น่าลองประเมินดูเหมือนกัน

  • สงสัยว่าส่วนที่บอกว่า zsh-syntax-highlighting จะไฮไลต์ทั้งบัฟเฟอร์ใหม่ทุกครั้งที่กดคีย์จนทำให้เกิดอาการหน่วงนั้น สังเกตได้ชัดในทางปฏิบัติจริงไหม
    ในตัวแก้ไขโค้ดก็ทำสิ่งที่โดยแก่นแล้วคล้ายกัน แต่แทบไม่รู้สึกถึงอาการหน่วงเลย บรรทัดคำสั่งเอง ต่อให้เป็นคำสั่งที่ถือว่า “ยาว” เมื่อเทียบกับมาตรฐานของ editor แล้วก็มักจะสั้นอยู่ดี เลยแปลกใจที่มันกลายเป็นปัญหาได้
    แต่ถ้า syntax highlighting ซับซ้อนกว่าที่คิดมาก ก็อาจเป็นไปได้

  • ได้เรียนรู้เคล็ดลับใหม่ ๆ เยอะจากบทความนี้ ก่อนหน้านี้ทำแค่ปรับพื้นฐานง่าย ๆ ไม่ให้ข้อมูลที่ใส่ใน prompt มาจากแบ็กเอนด์ที่ช้า
    แต่ที่นี่มีการ ปรับแต่ง prompt ให้มีประสิทธิภาพ อย่างละเอียดกว่านั้นมาก และในเวิร์กโฟลว์ประจำวันแบบที่เปิดเทอร์มินัลนับครั้งไม่ถ้วน การปรับเล็ก ๆ แบบนี้สะสมกันแล้วส่งผลใหญ่ได้