ชุมชน terminal emulator กำลังคึกคักไปด้วยการอภิปรายเรื่องประสิทธิภาพหลังจากการเปิดตัว Ghostty 1.2.0 แม้ว่าโปรเจกต์นี้จะได้รับความสนใจอย่างมากสำหรับเป้าหมายที่ทะเยอทะยานในการรวมความเร็ว ฟีเจอร์ และอินเทอร์เฟซผู้ใช้แบบ native แต่การทดสอบ latency ที่ดำเนินการโดยชุมชนเมื่อเร็วๆ นี้เผยให้เห็นภาพประสิทธิภาพที่ซับซ้อนกว่าที่คาดไว้ในตอนแรก
การตรวจสอบประสิทธิภาพอย่างจริงจัง
สมาชิกชุมชนได้นำ Ghostty มาทดสอบอย่างเข้มงวดโดยใช้ Typometer เครื่องมือเฉพาะทางที่ออกแบบมาเพื่อวัด visual latency ใน text editor และ terminal emulator ผลการทดสอบแสดงให้เห็นว่า Ghostty มี input latency เฉลี่ยอยู่ที่ 13.0 มิลลิวินาที ซึ่งทำให้อยู่ในตำแหน่งกลางๆ มากกว่าที่จะอยู่ในอันดับต้นๆ สำหรับประสิทธิภาพความเร็วแบบ raw
การทดสอบเผยให้เห็นการเปรียบเทียบที่น่าสนใจกับ terminal emulator ที่มีชื่อเสียง ตัวเลือกแบบดั้งเดิมอย่าง xterm ให้ latency ที่ต่ำกว่ามากที่ 3.5 มิลลิวินาทีเฉลี่ย ในขณะที่ Alacritty ทำได้ 4.2 มิลลิวินาที ประสิทธิภาพของ Ghostty เทียบเคียงได้กับ VS Code ที่ 13.0 มิลลิวินาที แต่ยังห่างไกลจากตัวเลือกที่เร็วที่สุดที่มีอยู่
Typometer: เครื่องมือ benchmarking เฉพาะทางที่วัดความล่าช้าระหว่างการกดแป้นพิมพ์และการปรากฏของตัวอักษรบนหน้าจอ
การเปรียบเทียบ Latency ของ Terminal Emulator (ผลลัพธ์จาก Typometer)
| Terminal Emulator | Latency ต่ำสุด (ms) | Latency สูงสุด (ms) | Latency เฉลี่ย (ms) | ส่วนเบี่ยงเบนมาตรฐาน |
|---|---|---|---|---|
| xterm 397 | 3.1 | 4.0 | 3.5 | 0.2 |
| Alacritty 0.15.1 | 3.6 | 4.8 | 4.2 | 0.2 |
| xfce4-terminal 1.1.4 | 2.9 | 6.8 | 4.4 | 0.3 |
| Ghostty 1.2.0 | 11.3 | 15.5 | 13.0 | 0.7 |
| kitty 0.42.2 | 11.7 | 21.3 | 15.8 | 3.3 |
| VS Code | 10.8 | 19.7 | 13.0 | 1.2 |
ค่า latency ที่ต่ำกว่าแสดงถึงประสิทธิภาพที่ดีกว่า
 |
|---|
| หน้าบันทึกการเปิดตัวที่เน้นเมตริกประสิทธิภาพและการปรับปรุงของ Ghostty 120 ซึ่งเกี่ยวข้องกับการอภิปรายประสิทธิภาพในชุมชน |
ฟีเจอร์ที่ขาดหายไปยังคงเป็นอุปสรรคสำหรับผู้ใช้
แม้จะมีการอภิปรายเรื่องประสิทธิภาพ แต่ผู้ใช้หลายคนชี้ให้เห็นว่าฟีเจอร์พื้นฐานที่ขาดหายไปเป็นความกังวลที่ใหญ่กว่า การขาดหายไปของฟังก์ชัน scrollback search ยังคงเป็นข้อจำกัดที่สำคัญสำหรับการใช้งานประจำวัน สมาชิกชุมชนแสดงความผิดหวังกับช่องว่างนี้ โดยเฉพาะผู้ที่พึ่งพาการนำทางประวัติ terminal อย่างหนัก
การขาดแคลน scrollbar แบบดั้งเดิมยังสร้างความท้าทายสำหรับผู้ใช้ที่เปลี่ยนมาจาก terminal emulator อื่นๆ แม้ว่า Ghostty จะรองรับ scrollback ผ่านทางลัด keyboard และการโต้ตอบด้วย mouse wheel แต่สัญญาณภาพของ scrollbar ยังคงขาดหายไปในรีลีสปัจจุบัน
ฟีเจอร์ที่วางแผนไว้สำหรับ Ghostty 1.3
- การค้นหาประวัติการเลื่อน: ฟังก์ชันการค้นหาข้อความแบบเต็มรูปแบบภายในประวัติของเทอร์มินัล
- แถบเลื่อน: ตัวบ่งชี้การเลื่อนแบบภาพเพื่อการนำทางที่ดีขึ้น
- การปรับปรุงความเท่าเทียมของฟีเจอร์: ความสามารถเพิ่มเติมเพื่อให้เทียบเท่ากับเทอร์มินัลอีมูเลเตอร์ยอดนิยม
ข้อจำกัดปัจจุบัน
- ไม่มีการกำหนดค่า GUI: มีเพียงการกำหนดค่าผ่านคำสั่งหรือไฟล์เท่านั้น
- ความพร้อมใช้งานในการแจกจ่ายที่จำกัด: ไม่มีในที่เก็บของ Debian และ Fedora
- การออกแบบที่เน้น GNOME: ใช้ไลบรารี libadwaita ซึ่งจำกัดการรวมธีมในสภาพแวดล้อมเดสก์ท็อปอื่นๆ
- ไม่มีฟังก์ชันการค้นหา: ไม่มีความสามารถในการค้นหาด้วย Ctrl+F ในเวอร์ชันปัจจุบัน
ความท้าทายด้านแพลตฟอร์มและการรวมระบบ
ผู้ใช้ Linux ได้แสดงความกังวลเกี่ยวกับการพึ่งพา libadwaita ของ Ghostty ซึ่งผูก terminal emulator เข้ากับภาษาการออกแบบของ GNOME อย่างใกล้ชิด แม้ว่าแอปพลิเคชันจะทำงานบน desktop environment อื่นๆ ได้ แต่ก็ไม่ได้รวมเข้ากับธีมและระบบ styling ที่ไม่ใช่ GNOME อย่างลงตัว
ความพร้อมใช้งานในการแจกจ่ายยังคงเป็นอุปสรรคอีกประการหนึ่ง โดย Ghostty ยังไม่ปรากฏใน package repository หลักอย่าง Debian และ Fedora สิ่งนี้จำกัดการเข้าถึงสำหรับผู้ใช้ที่ต้องการการติดตั้งที่จัดการโดยระบบมากกว่าการ build ด้วยตนเองหรือการแจกจ่าย AppImage
มองไปข้างหน้า
ทีมพัฒนาได้รับทราบข้อจำกัดเหล่านี้และได้วางแผนสำหรับเวอร์ชัน 1.3 รีลีสที่กำลังจะมาถึงสัญญาว่าจะแก้ไขฟีเจอร์ที่ขาดหายไปที่ได้รับการร้องขอมากที่สุด รวมถึงการใช้งาน scrollback search และ scrollbar การเพิ่มเติมเหล่านี้อาจปรับปรุงประสบการณ์การใช้งานประจำวันสำหรับผู้ใช้ terminal ระดับ power อย่างมีนัยสำคัญ
การตอบรับที่หลากหลายของชุมชนเน้นย้ำถึงความท้าทายที่การพัฒนา terminal emulator สมัยใหม่ต้องเผชิญ แม้ว่าแนวทางวิศวกรรมและการจัดการโปรเจกต์ของ Ghostty จะได้รับคำชม แต่ความเป็นจริงในทางปฏิบัติของการแข่งขันกับทางเลือกที่มีการปรับแต่งสูงและมีความเป็นผู้ใหญ่ยังคงเป็นเรื่องที่ต้องการความพยายาม ความสำเร็จของโปรเจกต์น่าจะขึ้นอยู่กับว่าจะสามารถสร้างสมดุลระหว่างชุดฟีเจอร์ที่ทะเยอทะยานกับความคาดหวังด้านประสิทธิภาพของผู้ใช้ที่เข้มงวดได้อย่างมีประสิทธิภาพเพียงใด
อ้างอิง: Obsidian 1.3.0