Điểm chuẩn của tiện ích mở rộng Swift so với phương thức: Swift 4.1 (Tháng 5 năm 2018)

Biểu đồ tương tác có sẵn tại đây: http://minikin.me/extensions

Động lực

Vài tuần trước tôi đã có một cuộc thảo luận với một lập trình viên iOS có nhiều niềm tin mạnh mẽ. Một trong số chúng nghe có vẻ như: Sử dụng các tiện ích mở rộng Swift là một thực tiễn rất tệ do thời gian biên dịch tăng đáng kể và giảm khả năng đọc và mã rõ ràng. Tôi sẽ không đánh giá về khả năng đọc và rõ ràng. Đó là những sở thích phong cách cá nhân, nhưng tôi khá bối rối với lập luận về thời gian biên dịch. Tôi nhớ lại đã có những cuộc thảo luận về chủ đề ba năm trở lên. Ba năm đối với Swift, âm thanh đối với tôi, giống như 50 năm đối với nhân loại. Tôi khá chắc chắn rằng tình hình không tệ như người này nghĩ, bởi vì tôi biết rằng nhóm Swift liên tục cải thiện ngôn ngữ, bao gồm cả thời gian biên dịch. Tôi không phải là một người sẽ tranh luận mà không có lập luận vững chắc.

Điểm chuẩn

Cuối tuần trước, tôi có vài giờ rảnh rỗi để kiểm tra tuyên bố của anh ấy. Tôi đã viết một tập lệnh ruby ​​để kiểm tra hiệu suất của các phần mở rộng so với các phương thức. Cách tiếp cận mà tôi đã chọn khá đơn giản, thậm chí có thể ngây thơ, nhưng dù sao tôi cũng muốn xem một số kết quả. Tôi đã kiểm tra các trường hợp sau:

  • Lớp + Phương thức
  • Lớp + Tiện ích mở rộng
  • Cấu trúc + Phương thức
  • Cấu trúc + Tiện ích mở rộng

Tập lệnh Ruby tạo các hàm số n cho mỗi trường hợp (ví dụ n = 3):

Lớp + Phương thức

lớp MyClass {
    cho n = 1000
    phương thức func_1 () {
      cho mục trong 0 .. 

Lớp + Tiện ích mở rộng

lớp MyClass {
    cho n = 1000
    phương thức func_1 () {
      cho mục trong 0 .. 

Tôi cũng muốn biết câu trả lời cho câu hỏi: Có bao nhiêu tiện ích mở rộng trong các ứng dụng Swift trong thế giới thực? Tôi đã kiểm tra các ứng dụng nguồn mở phổ biến nhất được viết bằng Swift và một vài ứng dụng mà chúng tôi đã phát triển trong công ty của chúng tôi cho khách hàng để biết một số tiện ích mở rộng.

Để chạy thử nghiệm, đặt USE_EXTENSIONS thành đúng hoặc sai trong Rakefile.

Chạy thử nghiệm:

điểm chuẩn

Kết quả kiểm tra dọn dẹp:

cào sạch

Kết quả

Khi nói đến việc đại diện cho dữ liệu được thu thập một cách rõ ràng và có ý nghĩa, các kỹ năng khoa học dữ liệu của tôi khá tiện dụng. Tôi đã tạo một kịch bản chính python để tạo các biểu đồ Bo mạch.

Biểu đồ tương tác có sẵn tại đây: http://minikin.me/extensions

Môi trường thử nghiệm: macOS 10.13.4, Swift 4.1, MacBook Pro 2016, Intel Core i7 2.6 GHz, LPDDR3 16 GB 2133 MHz

Kết luận

Trung bình, sử dụng phương pháp tiếp cận là từ -6% - 70% nhanh như triển khai tương đương với các tiện ích mở rộng.

Nhưng điều này có nghĩa là chúng ta không nên sử dụng phần mở rộng? Chắc là không.
Trong các ứng dụng thực tế, số lượng tiện ích mở rộng hiếm khi đạt tới 1000 và nếu có, sự khác biệt là khoảng 20%.

Chắc chắn, trong một ứng dụng thực tế, chúng tôi sẽ có kết quả khác nhau, nhưng được đo bằng chênh lệch thời gian tuyệt đối, khoản tiết kiệm khó có thể được đánh giá cao trong hầu hết các trường hợp.

Nếu bạn muốn thử nghiệm, bạn có thể kiểm tra repo trên GitHub.

Nếu bạn có bất kỳ câu hỏi nào, xin vui lòng liên hệ với tôi: @minikin

Cập nhật 1 (03.06.2018):

Yarik Arsenkin yêu cầu tôi thêm điểm chuẩn cho trường hợp Lớp + Hàm riêng trong Mở rộng so với Lớp + Phương thức riêng. Xin vui lòng, kiểm tra biểu đồ cập nhật và kết quả.