Bạn gọi nó là gì khi bạn thay đổi thời gian thực hiện Big O của một hàm [đã đóng]

Giả sử tôi có một chức năng sắp xếp cơ sở dữ liệu O(n^2)kịp thời. Tôi muốn tiến hành tái cấu trúc nó để nó chạy O(n log(n))đúng lúc và khi làm như vậy tôi sẽ thay đổi cách vận hành cơ bản, trong khi vẫn giữ các giá trị trả về và đầu vào tương đương.

Tôi gọi hoạt động tái cấu trúc này là gì?

"Tăng tốc-ifying" có vẻ không đúng lắm, vì bạn có thể làm cho thuật toán đi nhanh hơn mà không thay đổi tốc độ O lớn mà nó thực hiện.

"Đơn giản hóa" cũng không có vẻ đúng.

Tôi gọi hoạt động này là gì?

Cập nhật

Câu trả lời tốt nhất tôi có thể tìm thấy là giảm độ phức tạp thời gian tiệm cận.

Nó thường được gọi là "tối ưu hóa hiệu suất" , nhưng tôi sẽ không gọi nó là "tái cấu trúc", vì thuật ngữ này thường đề cập đến những thay đổi trong mã không thay đổi hành vi có thể nhìn thấy của nó . Và một sự thay đổi trong Big-O chắc chắn là thứ mà tôi sẽ gọi là sự thay đổi rõ ràng.

làm như vậy tôi sẽ thay đổi cách vận hành cơ bản

Trong trường hợp này, tối ưu hóa của bạn là viết lại chức năng đó. Không phải mọi tối ưu hóa, ngay cả khi nó thay đổi "Big-O", nhất thiết phải viết lại, đôi khi chỉ cần thay đổi nhỏ để đạt được sự cải thiện như vậy, nhưng ngay cả khi đó, tôi vẫn miễn cưỡng sử dụng thuật ngữ "tái cấu trúc" cho việc này, bởi vì nó có xu hướng cho một ấn tượng sai về bản chất của sự thay đổi.

EDIT: Tôi đã kiểm tra danh sách tái cấu trúc của Fowler , và trong số ~ 100 phép tái cấu trúc có tên này, cái cuối cùng được gọi là "Thuật toán thay thế" . Vì vậy, nếu chúng ta coi đây là tài liệu tham khảo chính tắc, có một khu vực nhỏ, màu xám trong đó tối ưu hóa hình thức được mô tả có thể được gọi là một loại tái cấu trúc đặc biệt (nhưng IMHO không phải là một điển hình). Cũng lưu ý, mục tiêu của Fowler với tất cả các phép tái cấu trúc là luôn cải thiện thiết kế với trọng tâm là khả năng duy trì và khả năng phát triển của mã hiện tại mà không cần viết lại và rõ ràng không phải là tối ưu hóa hiệu suất.

Tôi không nghĩ có một thuật ngữ tiêu chuẩn, một thuật ngữ thường được sử dụng là tối ưu hóa mặc dù cải thiện hoặc tăng tốc cũng sẽ đúng khi làm rõ rằng bạn đang nói về thay đổi mã và không thay đổi phần cứng.

Như những người khác đã nói, "tối ưu hóa" là thuật ngữ chung để cải thiện hiệu suất của thuật toán. Tuy nhiên, tối ưu hóa thường có nghĩa là cải thiện các yếu tố liên tục. Nếu tôi muốn nói ngắn gọn nhưng rõ ràng rằng tôi đã giảm độ phức tạp tiệm cận (thời gian), tôi đã nói rằng tôi đã "cải thiện hiệu suất tiệm cận". Đôi khi mọi người sẽ mô tả điều này là "cải thiện tỷ lệ" nhưng điều này đặc biệt mơ hồ ngày nay.

Cảnh báo : Giảm độ phức tạp thời gian tiệm cận không nhất thiết giống như tối ưu hóa trong bối cảnh thực tế . Thông thường các thuật toán không tối ưu không có triệu chứng được sử dụng bởi vì trên phạm vi đầu vào, chương trình thực sự được tiếp xúc với các thuật toán kém tối ưu hoạt động tốt hơn.

Nó sẽ phụ thuộc vào ngữ cảnh.

"Sửa lỗi hiệu năng thời gian chạy bậc hai" thường là những gì tôi thấy. Tuy nhiên, việc đó có đáng sửa hay không (thay đổi mã) là tùy thuộc vào ngữ cảnh.

Hãy nhớ rằng cơ sở dữ liệu cung cấp rất nhiều công cụ để cải thiện độ phức tạp thời gian. Ví dụ, để có được kết quả N hàng đầu từ cơ sở dữ liệu, chỉ cần nói như vậy. Khi chuyển đổi bùn không hiệu quả thành cuộc gọi được tối ưu hóa tích hợp, giải thích có vẻ không cần thiết.

Lý do tôi coi một thuật toán với thời gian chạy bậc hai để xứng đáng được xem xét mã (thảo luận) là không nhiều vì nó chậm (chậm là tương đối; bậc hai là nhanh khi so sánh theo cấp số nhân), nhưng vì trực giác của con người (như khách hàng của bạn, hoặc lập trình viên đồng nghiệp) vô cùng khó chịu với chức năng phần mềm đi quá xa so với thời gian chạy tuyến tính, do sự pha trộn của những kỳ vọng từ cuộc sống hàng ngày.

Rất nhiều phàn nàn của khách hàng về hiệu suất phần mềm thuộc hai loại sau:

• Toàn bộ hệ thống (phần mềm và phần cứng) được chỉ định dựa trên mức sử dụng ước tính. Tuần trước, mọi thứ đều chạy tốt, một chức năng nhất định chỉ mất chưa đến 5 giây. Tuần này, sau khi cài đặt bản cập nhật, chức năng tương tự mất hơn 1 phút.

  • Đây là một so sánh với một hiệu suất chuẩn trước đó. Khách hàng giữ hiệu suất trong tương lai đến một thước đo tuyệt đối theo thang thời gian của con người (từ giây đến phút).

• Tôi đã gửi 100 việc làm cho hệ thống. Tại sao phải mất 400 lần thời gian để xử lý, so với thời gian cần thiết cho một công việc?

  • Khách hàng mong đợi thời gian xử lý là tuyến tính. Trong thực tế, khách hàng không thể hiểu hoặc chấp nhận rằng có tồn tại các nhiệm vụ chậm hơn tuyến tính.

Vì lý do này, một khách hàng sẽ coi thời gian thực hiện là một lỗi nếu cả hai đều đúng:

• Chậm hơn tuyến tính
• Đáng chú ý (nghĩa là nằm trong phạm vi thời gian của con người (dài hơn giây hoặc phút) với các kích thước tác vụ thông thường)

Các đối số hợp pháp giải thích rằng thuật toán thời gian chạy bậc hai không gây ra vấn đề (nghĩa là không xứng đáng thay đổi mã):

• Kích thước của tác vụ thường được xử lý bởi hàm thời gian chạy bậc hai này có phần bị giới hạn
• Với phạm vi kích thước điển hình, thời gian thực hiện (tuyệt đối) vẫn đủ nhỏ để loại bỏ
• Nếu người dùng thực sự cố gắng gửi một tác vụ đủ lớn để có thể nhận thấy, người dùng sẽ nhận được một thông báo cảnh báo về thời gian chạy dài
• Những người sử dụng hệ thống đều là chuyên gia, do đó họ biết họ đang làm gì. Ví dụ: người dùng API nên đọc bản in đẹp trên tài liệu API.

Rất nhiều thuật toán hữu ích cho phát triển ứng dụng điển hình trên thực tế chậm hơn tuyến tính (chủ yếu là O (N log N), như trong cách sắp xếp), do đó, phần mềm quy mô lớn trên thực tế sẽ cố gắng giải quyết rằng, bằng cách chỉ sắp xếp phần có liên quan của dữ liệu hoặc sử dụng các kỹ thuật lọc biểu đồ (thống kê) đạt được hiệu quả tương tự.

Điều này áp dụng cho khách hàng phần mềm, nhưng nếu bạn coi người dùng của thư viện phần mềm hoặc hàm API là "khách hàng" thì câu trả lời vẫn sẽ được áp dụng.

Nếu thuật toán ban đầu được triển khai chính xác (hoặc bất kỳ lỗi nào không liên quan) thì "thay đổi thuật toán" hoặc "thay thế thuật toán" , vì những thay đổi đó có nghĩa là bạn đang thực hiện chính xác điều đó; thay thế một thuật toán với độ phức tạp thời gian khác nhau cho thuật toán được sử dụng trước đó.

Nếu sự phức tạp thời gian trước là do lỗi trong quá trình triển khai (ví dụ: bạn đã vô tình đặt lại điểm bắt đầu của một vòng lặp bên trong trên một chuỗi để cái mà lẽ ra O (n) trở thành O (n ² )) thì "sửa một lỗi chi phí bậc hai " hoặc tương tự.

Có sự trùng lặp, trong trường hợp như vậy, hiệu ứng trên mã là như nhau nếu bạn biết ngay từ đầu rằng công việc có thể được thực hiện trong thời gian O (n) và thời gian O (n ² ) là một lỗi, hoặc nếu Trước tiên, bạn cố tình triển khai nó trong thời gian O (n ² ) và sau đó nhận ra rằng nó vẫn hoạt động chính xác mà không cần đặt lại điểm bắt đầu và do đó thay thế thuật toán O (n) cho thuật toán O (n ² ).

Tối ưu hóa tốc độ bằng một đơn đặt hàng / đơn đặt hàng cường độ. Mặc dù đây là ngôn ngữ không chính xác về mặt toán học, nhưng nó truyền tải tốt nhất ý tưởng về Lệnh được thay đổi.

Cải thiện khả năng mở rộng. cũng nghe.