Khi nào hiệu suất đạt được đủ đáng kể để thực hiện tối ưu hóa đó?

Question

theo sách văn bản, tôi đo lường hiệu suất bất cứ khi nào tôi thử tối ưu hóa mã của mình. Đôi khi, tuy nhiên, hiệu suất đạt được là khá nhỏ và tôi không thể quyết định quyết định xem tôi nên thực hiện tối ưu hóa đó.

Ví dụ: khi sửa lỗi rút ngắn thời gian phản hồi trung bình từ 100ms xuống 90ms trong một số điều kiện, tôi có nên triển khai bản sửa lỗi đó không? Điều gì nếu nó rút ngắn 200ms đến 190ms? Tôi nên thử bao nhiêu điều kiện trước khi tôi có thể kết luận rằng nó sẽ mang lại lợi ích tổng thể?

Tôi đoán không thể đưa ra câu trả lời thẳng về vấn đề này, vì nó phụ thuộc vào quá nhiều thứ, nhưng có một nguyên tắc hay mà tôi nên theo dõi không? Có bất kỳ hướng dẫn/phương pháp hay nhất nào không?

EDIT: Cảm ơn câu trả lời tuyệt vời! Tôi đoán đạo đức của câu chuyện là, không có cách nào dễ dàng để nói liệu bạn có nên, nhưng có những hướng dẫn có thể hỗ trợ quá trình đó. Những điều bạn nên cân nhắc, những điều bạn không nên làm. thực hiện sửa chữa, mặc dù nó đã thực hiện một vài dòng mã thành 20-30 dòng mã. Bởi vì ứng dụng của chúng tôi. là hiệu suất rất quan trọng và đó là mức tăng 10% nhất quán trong các trường hợp thực tế khác nhau.

Answer 1

Tôi nghĩ rằng sự cai trị của ngón tay cái (ít nhất là đối với tôi) là hai mặt:

1. "Điều quan trọng nếu nó vấn đề "- trong thế giới kinh doanh, điều này thường có nghĩa là nó quan trọng nếu khách hàng quan tâm.Đó là, nếu người dùng cuối sẽ "nhận thấy" sự khác biệt giữa 100ms và 90ms (tôi không được facetious ở đây), sau đó nó quan trọng.
2. Nếu "điều quan trọng", thì bạn sẽ muốn kiểm tra mã của mình thật kỹ với nhiều loại trường hợp sử dụng có khả năng phát sinh hoặc ít nhất có thể phát sinh. Nếu một tối ưu hóa tăng tốc mã trong 50% các trường hợp, nhưng thực sự chạy chậm hơn so với những gì bạn đã có trước kia 50% thời gian, rõ ràng, nó có thể không có giá trị thực hiện.

Về điểm 1 ở trên: bằng cách đề xuất người dùng cuối phần mềm của bạn có thể "chú ý" chênh lệch 10ms, tôi không có ý đề nghị họ sẽ thấy rõ sự khác biệt. Nhưng nếu ứng dụng của bạn chạy trên một máy chủ có hàng triệu kết nối và mọi tốc độ tăng ít sẽ làm giảm tải đáng kể máy chủ, điều đó có thể quan trọng đối với ứng dụng khách đang chạy máy chủ. Hoặc nếu ứng dụng của bạn thực hiện công việc cực kỳ quan trọng về thời gian, đây là trường hợp khác mà kết quả của tốc độ 10ms có thể đáng chú ý, ngay cả khi tốc độ chính nó là thì không.

Answer 2

Nếu nó tăng tốc chương trình của bạn, tại sao không triển khai chương trình? Bạn đã thực hiện công việc bằng cách tạo triển khai mới, do đó bạn không thực hiện thêm công việc bằng cách áp dụng triển khai mới.

Trừ khi mã khó hiểu hơn nhiều.

Ngoài ra, 100 mili giây đến 90 mili giây là hiệu suất tăng 10%. Mức tăng 10% không nên được xem nhẹ.

Câu hỏi thực sự là, nếu nó chỉ mất 100 mili giây để chạy ngay từ đầu, thì điểm cố gắng tối ưu hóa nó là gì?

Answer 3

Donald Knuth đã hai câu sau đây về tối ưu hóa:

"Chúng ta nên quên đi nhỏ hiệu quả, nói rằng khoảng 97% thời gian : tối ưu hóa sớm là gốc của mọi tội lỗi" [2 ]

và

"Trong kỹ thuật lập môn một sự cải thiện 12%, dễ dàng thu được, không bao giờ được coi là biên và tôi tin rằng cùng một quan điểm nên ưu tiên áp dụng trong phần mềm kỹ thuật "[5]

src: http://en.wikipedia.org/wiki/Program_optimization

Answer 4

Chừng nào nó nhanh chóng đủ, sau đó bạn không cần phải tối ưu hóa nữa. Nhưng sau đó, bạn sẽ không còn bận tâm profiling nếu đó là trường hợp ...

Answer 5

Trong hầu hết các trường hợp, thời gian của bạn có giá trị hơn máy tính. Nếu bạn nghĩ rằng bạn sẽ mất nửa giờ để tìm ra mã đang làm gì sau này (nói nếu có lỗi trong đó), và nó chỉ tiết kiệm cho bạn một vài giây, bạn đã thua lỗ ròng.

Answer 6

Cách tiếp cận hợp lý duy nhất cho câu hỏi của bạn là một điều gì đó dọc theo dòng "khi lợi ích đủ lớn để đảm bảo thời gian bạn đầu tư khám phá, triển khai và thử nghiệm tối ưu hóa".

"Lợi ích đủ lớn" là cực kỳ chủ quan. Bạn hoặc chủ lao động của bạn có thể bán nhiều đơn vị phần mềm hơn nếu bạn thực hiện thay đổi này không? Thông báo cơ sở người dùng của bạn có được không? Nó sẽ cung cấp cho bạn sự hài lòng cá nhân để có mã nhanh nhất có thể? Câu hỏi nào trong số đó hoặc câu hỏi tương tự được áp dụng là điều duy nhất bạn có thể biết.

Bằng và lớn, phần lớn phần mềm tôi đã viết (trong vòng 20 năm) đã "đủ nhanh" ra khỏi hộp và mã tôi quan tâm để tối ưu hóa được trình bày như một nút cổ chai rõ ràng cho đến cuối người dùng: Truy vấn mất nhiều thời gian, di chuyển quá chậm, điều đó.

Answer 7

• Tối ưu hóa có làm xáo trộn mã của bạn quá nhiều không?
• Bạn có thực sự cần tối ưu hóa không? nếu ứng dụng của bạn chạy tốt thì khả năng đọc của mã có thể quan trọng hơn
• Bạn đã làm việc trên thiết kế chung và các thuật toán của ứng dụng của bạn trước khi thử tối ưu hóa hacky nhỏ?

Answer 8

Nếu hiệu suất đạt được nhỏ, hãy cân nhắc các yếu tố khác: bảo trì, rủi ro thay đổi, dễ hiểu, vv. Nếu nó cải thiện các thuộc tính đó, thì đó là lý do để thực hiện thay đổi.

Answer 9

Bạn nên tập trung nỗ lực tối ưu hóa vào các phần của mã chiếm thời gian chạy nhất. Nếu một đoạn mã cụ thể chiếm 80% tổng thời gian chạy, thì tối ưu hóa nó để giảm thời gian mất 5% sẽ có tác động nhiều như giảm thời gian còn lại của mã xuống 20%.

Nói chung, tối ưu hóa làm cho mã ít đọc hơn (không phải lúc nào cũng vậy nhưng thường). Vì vậy, bạn nên tránh tối ưu hóa cho đến khi bạn chắc chắn rằng có một vấn đề.

Answer 10

Phụ thuộc rất nhiều vào kịch bản sử dụng.Tôi sẽ giả định ở đây rằng mã trong câu hỏi đã được lược tả và do đó nó được gọi là nút cổ chai - tức là. không chỉ "điều này có thể nhanh hơn", nhưng "chương trình sẽ cho kết quả/kết thúc chạy nhanh hơn nếu điều này nhanh hơn". Trong những tình huống mà đây không phải là trường hợp - ví dụ: nếu bạn dành 99% thời gian của bạn chờ đợi nhiều dữ liệu hơn để đi qua kết nối ethernet - thì bạn nên quan tâm về tính chính xác nhưng không tối ưu hóa tốc độ.

• Nếu bạn đang viết một đoạn mã giao diện người dùng, điều bạn quan tâm là tốc độ cảm nhận. Nói chung bất cứ điều gì dưới ~ 100 ms được coi là "tức thời" - không có điểm nào tăng tốc nó lên.
• Nếu bạn đang viết một đoạn mã cho một trang trại máy chủ khổng lồ, sau đó nếu chi phí tiền lương của bạn để làm cho mã nhanh hơn ít hơn chi phí của điện thêm cho trang trại máy chủ, nó là đáng giá. (Nhưng hãy chắc chắn để ưu tiên thời gian của bạn.)
• Nếu bạn đang viết một đoạn mã được sử dụng hiếm khi hoặc khi không giám sát, miễn là nó hoàn thành trong một khoảng thời gian bán sane, đừng lo lắng về nó. Cài đặt tập lệnh có xu hướng thuộc loại này (trừ khi bạn bắt đầu chạy vào nhiều phút, tại thời điểm đó người dùng có thể bắt đầu bỏ cài đặt vì quá trình này mất quá nhiều thời gian).
• Nếu bạn đang viết mã để tự động hóa tác vụ cho người khác, thì nếu (thời gian bạn dành mã hóa + thời gian sử dụng mã tối ưu) ít hơn (thời gian sử dụng mã chậm), thì đáng giá. Nếu bạn đang làm điều này trong một thiết lập thương mại, hãy cân nhắc điều này bằng mức lương tương ứng của bạn.
• Nếu bạn đang viết mã thư viện sẽ được nhiều nghìn người sử dụng, hãy luôn làm cho nó nhanh hơn nếu bạn có thời gian.
• Nếu bạn dưới áp lực thời gian chỉ đơn giản là có một cái gì đó hoạt động, ví dụ: như là một bản demo, không tối ưu hóa (ngoại trừ thông qua sự lựa chọn hợp lý của các thuật toán từ các thư viện), trừ khi kết quả sẽ rất chậm mà nó thậm chí không "làm việc".

Một trong những phiền toái lớn nhất đối với cá nhân tôi là tìm phần mềm mà ban đầu có thể rơi vào một danh mục và sau đó rơi vào một danh mục khác, nhưng không ai trở lại để tối ưu hóa cần thiết. Cho đến gần đây hiệu suất Javascript là một ví dụ tuyệt vời về điều này. Đạo đức của câu chuyện là: không chỉ quyết định một lần; xem xét lại vấn đề theo yêu cầu của tình huống.