- What the Fork เป็นเครื่องมือข้ามแพลตฟอร์มที่ใช้ แสดงภาพกระบวนการบิลด์แบบเรียลไทม์สำหรับ C/C++/Rust และอื่น ๆ
- ช่วยให้มองเห็นปัญหาเชิงโครงสร้างของระบบบิลด์เดิมได้ง่าย เช่น การประมวลผลแบบขนานที่ไม่เพียงพอ และกระบวนการที่ไม่มีประสิทธิภาพ
- ทำงานได้กับทุกระบบบิลด์และทุกภาษาโปรแกรม และรองรับ เครื่องมือบิลด์หลากหลาย เช่น make, ninja, gradle, zig, cargo
- ใช้ การมอนิเตอร์ system call เพื่อแสดงภาพเวลาในการทำงาน คำสั่ง และความสัมพันธ์ของการพึ่งพาระหว่างแต่ละโปรเซสในรูปแบบกล่อง
- เป็นเครื่องมือที่มีประโยชน์มากสำหรับการปรับแต่งบิลด์ การวิเคราะห์คอขวด และการปรับปรุงประสิทธิภาพ CI
บทนำและที่มา
- What the Fork เป็นเครื่องมือแสดงภาพการบิลด์แบบเรียลไทม์ที่พัฒนาขึ้นเพื่อวินิจฉัยสาเหตุที่ทำให้การบิลด์ช้าผ่านภาพที่เข้าใจง่าย
- บางโปรเจ็กต์อย่าง LLVM อาจคอมไพล์ช้าเพราะปริมาณโค้ดมีมากจริง แต่การบิลด์ส่วนใหญ่มักใช้เวลานานเกินจำเป็นเพราะการตั้งค่าที่ไม่มีประสิทธิภาพ
- ที่ผ่านมา การตรวจสอบปัญหาของการบิลด์โดยตรงหรือมองเห็นปัญหาเชิงโครงสร้างได้ในภาพรวมทำได้ยาก จึงเกิดความต้องการเครื่องมือนี้
- เครื่องมือนี้ถูกออกแบบมาให้เป็นแบบข้ามแพลตฟอร์ม และใช้ได้กับทุกระบบบิลด์และทุกภาษา
ฟีเจอร์หลักและวิธีใช้งาน
- What the Fork ไม่ใช่เพียง system profiler ทั่วไป แต่เป็นเครื่องมือสำหรับวินิจฉัยปัญหาที่เฉพาะกับงานบิลด์
- ตัวอย่างเช่น การไม่ใช้แฟล็ก
-j เมื่อใช้ make, การกระจุกตัวของเวลาในไฟล์หรือขั้นตอนคอมไพล์บางจุด, และการตรวจจับคำสั่งที่ทำงานแบบลำดับทั้งที่สามารถทำแบบขนานได้
- มีประสิทธิภาพอย่างมากโดยเฉพาะกับการวิเคราะห์และปรับแต่งประสิทธิภาพของ clean build ใน สภาพแวดล้อม CI
- วิธีใช้คือใส่คำสั่ง
wtf นำหน้าคำสั่งบิลด์ (เช่น wtf make, wtf cargo build, wtf npm run build)
- เมื่อเริ่มบิลด์แล้ว UI จะทำงานและอัปเดตสถานะความคืบหน้าของแต่ละโปรเซสแบบเรียลไทม์
UI และวิธีการแสดงภาพ
- แต่ละโปรเซสของการบิลด์จะแสดงบนไทม์ไลน์ในรูปแบบกล่อง และแยกประเภทด้วยสี
- ความสัมพันธ์แบบพ่อ-ลูกของโปรเซสจะแสดงเป็นโครงสร้างซ้อนกัน
- แผงด้านล่างจะแสดงเวลาในการรันของโปรเซสที่เลือก ไดเรกทอรีทำงาน และข้อมูลอาร์กิวเมนต์ของคำสั่งทั้งหมด
หลักการทำงาน
- การบิลด์คือการทำงานร่วมกันของหลายโปรเซส (เช่น
bash, clang, ld)
- การบิลด์ขนาดใหญ่ใช้เครื่องมือบิลด์หลากหลาย เช่น
cargo, make, bazel, gradle, xcodebuild ซึ่งเบื้องหลังทำงานกับคำสั่งจำนวนมาก การพึ่งพา แคช และการจัดตารางงาน
- การดูแค่เอาต์พุตในเทอร์มินัลไม่สามารถทำให้เข้าใจโปรเซสที่ซ้อนกันอยู่ (เช่น
ld ที่ clang เรียกภายใน) และโครงสร้างเวลาอย่างละเอียดได้
- เพื่อแก้ปัญหานี้ เครื่องมือจึงใช้ system call ที่ตรวจจับการเริ่มต้นและสิ้นสุดของโปรเซส ตามแต่ละระบบปฏิบัติการ (macOS: Endpoint Security API, Linux:
ptrace(), Windows: Event Tracing for Windows)
- ด้วยวิธีนี้จึงสามารถกู้คืนลำดับเวลาของกระบวนการบิลด์ทั้งหมด และระบุเส้นทางการทำงานกับเวลาที่ใช้ในแต่ละขั้นตอนได้
- นอกจากงานบิลด์แล้ว ยังสามารถนำไปใช้ติดตาม subprocess รูปแบบต่าง ๆ ได้ด้วย
กรณีใช้งานจริงและสิ่งที่ค้นพบ
- วิศวกรหลายคน (จาก Delta, Mozilla, Apple) ได้นำไปใช้กับโปรเจ็กต์จริงและพบปัญหาที่ไม่คาดคิด
- ตัวอย่าง 1: ในโปรเจ็กต์โอเพนซอร์สที่ใช้ Cargo พบว่าไฟล์ต่าง ๆ ถูกคอมไพล์แบบลำดับ ทำให้เห็นชัดว่าขาดการทำงานแบบขนาน (บน CPU 10 คอร์มีศักยภาพในการเร่งความเร็วได้มากกว่า 10 เท่า)
- ตัวอย่าง 2: ในการบิลด์ LLVM ด้วย Ninja ทุกคอร์ของ CPU ทำงานแบบขนานได้อย่างมีประสิทธิภาพ จนได้ประสิทธิภาพการบิลด์ที่ใกล้อุดมคติ
- ตัวอย่าง 3: ในโปรเจ็กต์ที่ใช้ CMake พบโครงสร้างที่ไม่มีประสิทธิภาพ โดยมีการรันซ้อนของ cmake/make/clang และมีการตรวจสอบเวอร์ชัน Xcode/OS ซ้ำถึง 85 ครั้ง ทั้งที่งานจริงมีเพียงเล็กน้อย
- ตัวอย่าง 4: ในโปรเจ็กต์ Objective-C ขนาดใหญ่ที่ใช้ xcodebuild พบว่าช่วงท้ายของการบิลด์มีการประมวลผลแบบขนานไม่เพียงพอ และก่อนเริ่มบิลด์ยังมีช่วงที่ไม่มีการทำงานยาว 6 วินาที (ขณะที่ ninja เริ่มคอมไพล์ได้ภายใน 0.4 วินาที)
- ตัวอย่าง 5: เมื่อ Zig คอมไพล์ Orca Project ลำดับการบิลด์ของ dependency ถูกกำหนดแบบสุ่ม ทำให้ประสิทธิภาพของการประมวลผลแบบขนานเปลี่ยนไปตามดวง โดยมีบาง dependency ถูกเลื่อนไปทำช่วงท้ายจนลดความขนานลง
- ตัวอย่าง 6: ในโปรเจ็กต์ GitHub CLI ที่ใช้ make/go พบว่าเวลาสำหรับดาวน์โหลด dependency สูงมาก จึงคาดว่าจะปรับความเร็วการบิลด์ได้หากลด dependency ลง
ผลลัพธ์จากการใช้งานและข้อจำกัด
- การวิเคราะห์ไทม์ไลน์แบบภาพช่วยให้ค้นพบคอขวดที่ไม่คาดคิด การพึ่งพาที่ซ้ำซ้อนโดยไม่จำเป็น และจุดที่ขาดความขนานได้
- สามารถระบุจุดปรับปรุงเชิงโครงสร้างได้อย่างรวดเร็ว เช่น ปัญหา dependency การทำงานซ้ำโดยไม่จำเป็น หรือความไม่มีประสิทธิภาพของเครื่องมือบางชนิด เพื่อนำไปใช้ปรับแต่งประสิทธิภาพการบิลด์ได้โดยตรง
- การดูคำสั่งทั้งหมดของแต่ละโปรเซสยังช่วยให้วิเคราะห์ได้ละเอียดมากขึ้น
โปรแกรมเบต้า
- What the Fork ทำงานได้บน Windows, Linux และ macOS
- บุคคลหรือทีมที่ต้องการให้ฟีดแบ็กสามารถสมัครเข้าร่วม private beta ได้ (มีลิงก์ Google Form ให้)
ยังไม่มีความคิดเห็น