Swift, ngôn ngữ lập trình hiện đại của Apple, đang phải đối mặt với những chỉ trích ngày càng gia tăng từ các nhà phát triển về hiệu suất trình kiểm tra kiểu. Các cuộc thảo luận gần đây trong cộng đồng nhà phát triển làm nổi bật sự thất vọng lan rộng về thời gian biên dịch có thể kéo dài đến hàng chục giây ngay cả với những biểu thức có vẻ đơn giản, làm dấy lên câu hỏi về tính phù hợp của ngôn ngữ này cho các dự án phát triển quy mô lớn.
Vấn Đề Hiệu Suất Không Ngừng Kéo Dài
Các nhà phát triển báo cáo gặp phải sự chậm trễ trong kiểm tra kiểu ảnh hưởng đáng kể đến năng suất của họ. Một ví dụ đặc biệt rõ ràng liên quan đến một biểu thức nối chuỗi đơn giản được cho là mất 10 giây để kiểm tra kiểu trong các phiên bản Swift trước đó, và các cải tiến chỉ giúp giảm thời gian này xuống còn 6 giây trong các bản cập nhật gần đây. Đối với các nhà phát triển làm việc trên phần cứng Apple hiện đại như Mac M2, những vấn đề hiệu suất này đặc biệt đáng lo ngại khi xét đến sức mạnh phần cứng sẵn có.
Tôi kỳ vọng một biểu thức như vậy phải được kiểm tra kiểu nhanh hơn cả triệu lần - ít nhất là như thế.
Vấn đề cốt lõi bắt nguồn từ hệ thống kiểm tra kiểu dựa trên ràng buộc của Swift, hệ thống này phải xử lý các tổ hợp phức tạp của các toán tử quá tải và suy luận kiểu. Chỉ riêng trong thư viện chuẩn đã có 17 phiên bản quá tải của toán tử + và 9 kiểu áp dụng giao thức ExpressibleByStringLiteral, trình biên dịch phải đối mặt với độ phức tạp theo cấp số nhân ngay cả khi phân giải các biểu thức cơ bản.
Những Nguyên Nhân Chính Gây Ra Vấn Đề Hiệu Suất Trong Swift
- 17 phiên bản nạp chồng của toán tử
+trong thư viện chuẩn - 9 kiểu dữ liệu áp dụng giao thức
ExpressibleByStringLiteral - Độ phức tạp của suy luận kiểu hai chiều
- Giải quyết nạp chồng theo phương thức tùy biến
Các Lựa Chọn Kiến Trúc Bị Xem Xét Kỹ Lưỡng
Hai tính năng ngôn ngữ cụ thể dường như là nguyên nhân chính gây ra các vấn đề hiệu suất: suy luận kiểu hai chiều và quá tải ad-hoc. Suy luận hai chiều cho phép các kiểu di chuyển cả lên trên và xuống dưới qua cây biểu thức, trong khi quá tải cho phép nhiều hàm chia sẻ cùng một tên với các kiểu tham số khác nhau. Mặc dù các tính năng này cho phép cú pháp Swift sạch sẽ và biểu cảm, chúng đi kèm với một chi phí tính toán đáng kể.
Lộ trình của nhóm phát triển Swift thừa nhận những thách thức này nhưng dừng lại ở việc đề xuất các giải pháp triệt để như loại bỏ hoàn toàn tính năng quá tải, vì nhận ra rằng những thay đổi như vậy sẽ phá vỡ khả năng tương thích với các codebase Swift hiện có. Thay vào đó, họ đang tập trung vào các cải tiến gia tăng cho các thuật toán trình giải ràng buộc và hệ thống chẩn đoán.
Tác Động Thực Tế Đến Quy Trình Phát Triển
Các vấn đề hiệu suất có những hậu quả thực tế đối với quy trình làm việc hàng ngày của các nhà phát triển. Nhiều người báo cáo dành nhiều thời gian chờ biên dịch chỉ để nhận được các thông báo lỗi khó hiểu, cung cấp rất ít hướng dẫn để khắc phục các vấn đề cơ bản. Vấn đề này trở nên đặc biệt nghiêm trọng trong phát triển SwiftUI, nơi các hệ thống phân cấp view phức tạp và cú pháp closure đuôi có thể tạo ra cơn ác mộng cho việc kiểm tra kiểu.
Một số nhà phát triển đã áp dụng các phương pháp lập trình phòng thủ để giải quyết những hạn chế này, bao gồm chú thích kiểu rõ ràng ở mọi nơi và tránh các chuỗi thao tác dài. Tuy nhiên, những giải pháp này làm suy yếu mục tiêu của Swift là cung cấp cú pháp sạch sẽ, dễ đọc và đặt thêm gánh nặng lên các nhà phát triển khi phải tự quản lý những gì lẽ ra nên được tự động hóa bởi trình biên dịch.
Giải pháp tạm thời của nhà phát triển
- Chú thích kiểu dữ liệu rõ ràng cho tất cả các biến
- Tránh trộn lẫn số nguyên và số thực mà không ép kiểu tường minh
- Chia nhỏ các chuỗi thao tác dài thành các câu lệnh riêng biệt
- Giảm thiểu việc sử dụng trailing closures trong các biểu thức phức tạp
Phản Ứng Của Cộng Đồng Và Các Nền Tảng Thay Thế
Các vấn đề hiệu suất dai dẳng đã khiến một số nhà phát triển xem xét lại lựa chọn nền tảng của họ. Sự thất vọng rõ rệt trong các cuộc thảo luận cộng đồng, với một số bình luận bày tỏ nghi ngờ về việc tiếp tục đầu tư vào hệ sinh thái Swift. Một số lưu ý rằng khoảng một phần ba ứng dụng trên App Store hiện được xây dựng bằng Flutter thay vì Swift gốc, cho thấy các vấn đề hiệu suất có thể đang đẩy các nhà phát triển tìm đến các công nghệ thay thế.
Tình hình này cũng làm dấy lên sự so sánh với cách tiếp cận của Chris Lattner với Mojo, một ngôn ngữ mới hơn đi theo một hướng kiến trúc khác cho hệ thống kiểu của nó. Trong khi Swift tiếp tục phát triển, cộng đồng dường như bị chia rẽ giữa những người sẵn sàng chấp nhận các hạn chế hiện tại và những người tìm kiếm các giải pháp cơ bản hơn.
Cải Thiện Hiệu Suất Type Checking Của Swift
- Swift 5.6: Tối ưu hóa ban đầu cho constraint solver
- Swift 5.7: Giảm thêm thời gian type checking (7s → 0.6s trong một số trường hợp)
- Nhánh phát triển: Cải tiến thuật toán bổ sung (giảm xuống 0.17s cho các biểu thức cụ thể)
Hướng Tới Tương Lai
Nhóm phát triển Swift tiếp tục làm việc để cải thiện, với các phiên bản gần đây cho thấy tiến bộ đáng kể. Swift 5.6 và 5.7 đã chứng minh những cải thiện hiệu suất đáng kể trong các tình huống cụ thể, với một số biểu thức phức tạp có thời gian kiểm tra kiểu giảm từ 7 giây xuống còn 0,6 giây. Các công việc đang tiến hành tập trung vào tối ưu hóa suy luận phép tuyển, xử lý các giải pháp một phần hiệu quả hơn và cải thiện chẩn đoán ở chế độ ẩn.
Tuy nhiên, sự căng thẳng cơ bản giữa cú pháp biểu cảm của Swift và khả năng biên dịch hiệu suất cao vẫn chưa được giải quyết. Khi ngôn ngữ này tiếp tục trưởng thành, việc cân bằng các ưu tiên cạnh tranh này sẽ rất quan trọng để duy trì sự hài lòng và mức độ áp dụng từ các nhà phát triển. Cộng đồng đang theo dõi sát sao, hy vọng rằng các bản cập nhật trong tương lai sẽ mang lại cả cú pháp sạch đẹp mà họ yêu thích lẫn hiệu suất mà họ cần.
Lưu ý: Kiểm tra kiểu dựa trên ràng buộc sử dụng một hệ thống các ràng buộc kiểu phải được thỏa mãn, tương tự như giải một câu đố mà mỗi mảnh ghép phải phù hợp với các quy tắc cụ thể. Lưu ý: Suy luận kiểu hai chiều cho phép trình biên dịch suy ra các kiểu bằng cách phân tích cả ngữ cảnh sử dụng biểu thức và các thành phần của biểu thức đó.
Tham khảo: Lộ trình cải thiện trình kiểm tra kiểu