What the Fork - Công cụ trực quan hóa build C/C++/Rust theo thời gian thực

• What the Fork là một công cụ đa nền tảng giúp trực quan hóa theo thời gian thực nhiều quy trình build khác nhau như C/C++/Rust
• Có thể dễ dàng xác định các vấn đề mang tính cấu trúc của hệ thống build hiện có như thiếu xử lý song song, quy trình kém hiệu quả
• Hoạt động với mọi hệ thống build và ngôn ngữ lập trình, hỗ trợ nhiều công cụ build như make, ninja, gradle, zig, cargo
• Thông qua giám sát system call, công cụ trực quan hóa thời gian thực thi, lệnh và quan hệ phụ thuộc của từng tiến trình dưới dạng các hộp
• Đây là công cụ rất hữu ích cho tối ưu hóa build, phân tích điểm nghẽn và cải thiện hiệu năng CI

---

Giới thiệu và bối cảnh

• What the Fork là công cụ trực quan hóa build theo thời gian thực được phát triển để chẩn đoán trực quan nguyên nhân khiến build chậm
• Với những dự án như LLVM, tốc độ biên dịch có thể chậm đơn giản vì lượng mã quá lớn, nhưng phần lớn các bản build lại mất thời gian không cần thiết do cấu hình kém hiệu quả
• Trước đây, rất khó tự kiểm tra trực tiếp các vấn đề của build hoặc nhìn ra các vấn đề mang tính cấu trúc chỉ trong một cái nhìn, vì vậy cần có công cụ như thế này
• Công cụ này được thiết kế đa nền tảng và có thể áp dụng cho mọi hệ thống build và ngôn ngữ

Tính năng chính và cách dùng

• What the Fork không chỉ là một system profiler đơn thuần mà là công cụ chuyên dùng để chẩn đoán các vấn đề đặc thù của build
• Ví dụ có thể phát hiện việc không dùng cờ -j khi chạy make, thời gian bị dồn vào một tệp hoặc một bước biên dịch cụ thể, hay các lệnh lẽ ra có thể chạy song song nhưng lại bị thực thi tuần tự
• Đặc biệt hiệu quả trong việc phân tích và tối ưu hiệu năng clean build trong môi trường CI
• Cách dùng là thêm lệnh wtf vào trước lệnh build để chạy (ví dụ: wtf make, wtf cargo build, wtf npm run build)
• Khi build bắt đầu, giao diện UI sẽ chạy và cập nhật theo thời gian thực trạng thái tiến hành của từng tiến trình

UI và cách trực quan hóa

• Mỗi tiến trình build được hiển thị trên timeline dưới dạng hộp, với màu sắc để phân biệt loại
• Quan hệ cha-con giữa các tiến trình được thể hiện bằng cấu trúc lồng nhau
• Ở bảng phía dưới, công cụ hiển thị thời gian thực thi, thư mục làm việc và toàn bộ tham số dòng lệnh của tiến trình đang được chọn

Nguyên lý hoạt động

• Một bản build là sự kết hợp của nhiều tiến trình khác nhau (ví dụ: bash, clang, ld)
• Các bản build quy mô lớn sử dụng nhiều công cụ build như cargo, make, bazel, gradle, xcodebuild, và trên thực tế các công cụ này thực hiện rất nhiều lệnh, phụ thuộc, bộ nhớ đệm và tác vụ lập lịch
• Chỉ nhìn vào đầu ra terminal thì không thể nắm được các tiến trình lồng nhau (ví dụ: ld được clang gọi nội bộ) cùng cấu trúc thời gian chi tiết
• Để làm điều đó, công cụ sử dụng các system call phát hiện việc bắt đầu và kết thúc tiến trình theo từng hệ điều hành (macOS: Endpoint Security API, Linux: ptrace(), Windows: Event Tracing for Windows)
• Với cách này, có thể khôi phục toàn bộ quá trình build và timeline, đồng thời xác định đường thực thi và thời gian của từng giai đoạn
• Ngoài build, công cụ còn có thể được dùng để theo dõi nhiều subprocess khác

Trường hợp thực tế và kết quả quan sát

• Nhiều kỹ sư (thuộc Delta, Mozilla, Apple) đã áp dụng công cụ này vào dự án thực tế và phát hiện những vấn đề không ngờ tới
• Ví dụ 1: Trong một dự án mã nguồn mở dùng Cargo, các tệp được biên dịch tuần tự, qua đó xác nhận thiếu tính song song (trên CPU 10 lõi có khả năng cải thiện tốc độ hơn 10 lần)
• Ví dụ 2: Trong bản build LLVM dùng Ninja, tất cả các lõi CPU đều thực hiện công việc song song hiệu quả, đạt hiệu suất build lý tưởng
• Ví dụ 3: Trong một dự án dựa trên CMake, phát hiện cấu trúc kém hiệu quả khi cmake/make/clang được chạy lồng nhau và việc kiểm tra lại phiên bản Xcode/OS bị lặp tới 85 lần (trong khi công việc thực sự chỉ chiếm một phần rất nhỏ)
• Ví dụ 4: Trong một dự án Objective-C lớn dùng xcodebuild, phát hiện thiếu xử lý song song ở giai đoạn cuối của build và tồn tại 6 giây không hoạt động trước khi build bắt đầu (trong khi ninja bắt đầu biên dịch gần như ngay sau 0,4 giây)
• Ví dụ 5: Khi Zig biên dịch Orca Project, thứ tự build các phụ thuộc được quyết định ngẫu nhiên, khiến hiệu quả xử lý song song thay đổi tùy may rủi. Quan sát thấy một số phụ thuộc bị đẩy xuống chạy ở cuối làm giảm tính song song
• Ví dụ 6: Trong dự án GitHub CLI dùng make/go, thời gian tải phụ thuộc khá lớn. Nếu giảm số lượng phụ thuộc, tốc độ build được kỳ vọng sẽ cải thiện

Hiệu quả sử dụng và giới hạn

• Thông qua phân tích timeline trực quan, có thể phát hiện các điểm nghẽn bất ngờ, sự lặp lại phụ thuộc không cần thiết và những khu vực thiếu tính song song
• Có thể nhanh chóng xác định các điểm cần cải thiện về mặt cấu trúc như vấn đề phụ thuộc, tái thực thi không cần thiết hoặc sự kém hiệu quả của một công cụ cụ thể, từ đó trực tiếp tối ưu hiệu năng build
• Việc xem toàn bộ câu lệnh của tiến trình cũng cho phép phân tích chi tiết hơn

Chương trình beta

• What the Fork hoạt động trên Windows, Linux và macOS
• Cá nhân và đội nhóm muốn gửi phản hồi có thể đăng ký tham gia beta riêng tư (có cung cấp liên kết Google Form)