Tại điểm nào bạn nên bắt đầu suy nghĩ về hiệu suất?

Khi tôi đang xây dựng các ứng dụng, tôi thấy mình liên tục hỏi liệu đây có phải là cách tốt nhất để thực hiện hoặc thực hiện một chức năng nhất định. Thông thường, tôi sẽ đăng câu hỏi trên stackoverflow hoặc một diễn đàn khác mong muốn phản hồi chỉ để nhận được ý kiến ​​về cách không "đặt giỏ hàng trước ngựa" liên quan đến hiệu suất. Có phải hầu hết các lập trình viên thực sự không nghĩ về hiệu suất cho đến khi ứng dụng kết thúc, hoặc hiệu suất là hoàn toàn không thể chấp nhận ?? Ý tôi là, tôi hiểu rằng môi trường phát triển khác với môi trường sản xuất và bạn không nên hoàn toàn dựa vào kết quả từ máy tính xách tay dev của mình ... nhưng, có những thực tiễn và kỹ thuật mang lại hiệu suất tốt hơn những môi trường khác.

Có phải thực tế xấu khi xem xét hiệu suất trong suốt quá trình phát triển? Tôi có nên đẩy những cân nhắc này ra cho đến khi hiệu suất thực sự tăng?

Cập nhật

Nói rõ hơn, tôi đang nói về tình huống mà bạn đang xem xét hoặc sắp làm việc với một số chức năng. Bạn biết có một số cách để thực hiện nó, nhưng bạn không chắc chắn mỗi lần thực hiện sẽ mở rộng như thế nào. Ngoài ra có thể có một số kỹ thuật bạn thậm chí không quen thuộc. Ở quy mô nhỏ, bất kỳ phương pháp tiếp cận nào cũng có thể là đầy đủ, nhưng ở quy mô lớn hơn, một số sẽ theo kịp và một số thì không. Thông thường khi tôi hỏi ý kiến ​​hoặc hướng dẫn, câu trả lời là: lo lắng về điều đó sau ...

Việc trì hoãn các cân nhắc về hiệu suất đôi khi dựa trên việc sử dụng sai cụm từ:

Tối ưu hóa sớm là gốc rễ của mọi tội lỗi.

Nếu bạn đọc trích dẫn đầy đủ, điều Knuth đã cố gắng nói là tối ưu hóa vi mô được áp dụng trong quá trình phát triển mà không có hồ sơ nói chung là không thể, bởi vì chúng dẫn đến mã ít bảo trì hơn mà không nhất thiết phải đạt được lợi ích hiệu suất đáng kể.

Nhưng điều đó không có nghĩa là bạn không nên xem xét hiệu suất cho đến khi ứng dụng gần hoàn tất. Nếu bạn làm điều đó, bạn có thể thấy rằng hiệu suất là không đủ, kiến ​​trúc thiết kế của bạn không hỗ trợ hiệu suất tốt hơn và bạn phải bắt đầu lại.

Có một số điều bạn có thể làm trong quá trình phát triển để đạt được hiệu suất tốt, mà không cần tối ưu hóa bí truyền (và sớm):

1. Sử dụng một kiến ​​trúc hợp lý, chu đáo.
2. Sử dụng cấu trúc dữ liệu đúng cách.
3. Sử dụng các công nghệ (thư viện, khung) thực hiện đầy đủ.

Nếu bạn làm những điều này, bạn sẽ thấy rằng bất kỳ tối ưu hóa hiệu suất nào cần phải xảy ra sẽ bị giới hạn trong một phần nhỏ của mã của bạn. Profiling sẽ xác định mã đó và cho phép bạn tập trung vào các cải tiến hiệu suất của mình, nơi chúng sẽ làm tốt nhất, mà không phải hy sinh khả năng bảo trì.

Đây là những gì KHÔNG nên nghĩ về:

• Là ++inhanh hơn i++?
• Là switchnhanh hơn if?
• Tôi có nên inlinechức năng của tôi?
• Các chức năng ảo có chậm không?
• Là C ++ / Java / C # nhanh hơn / chậm hơn so với cái khác?
• blah, blah, ...

Đây là những gì cần suy nghĩ:

• Khối lượng công việc dự kiến ​​thực tế là gì?
• Làm thế nào thường xuyên thông tin đầu vào thay đổi, và ai cung cấp nó? Liệu nó có ý nghĩa để xem xét tiền biên dịch?
• Tôi có giữ cấu trúc dữ liệu của mình đơn giản và bình thường nhất có thể không? Điều đó có nghĩa là không lo lắng về băm và những thứ như vậy.
• Tôi đã giữ thông báo đến mức tối thiểu? (Đó là nơi thay đổi trong một phần của dữ liệu yêu cầu thay đổi cùng thời gian ở phần khác, vì cấu trúc dữ liệu không được chuẩn hóa.)

Về điểm thứ hai, theo kinh nghiệm của tôi, tốt nhất là thiết kế cấu trúc dữ liệu để nếu nó không được chuẩn hóa, nó có thể chịu được sự không nhất quán tạm thời, sau này có thể được giải quyết bằng một số lần quét định kỳ. Một kẻ giết người hiệu suất chính là khi các thông báo kích hoạt các thông báo tiếp theo, sẽ kích hoạt thêm, đến một mức độ mà bạn sẽ không bao giờ đoán được trước đó. Và thường thì lãng phí công sức vì những thay đổi tự hủy.

Nếu bạn đã làm tất cả điều này, bạn có một thiết kế sạch sẽ. Sau đó định kỳ khi bạn phát triển nó, hồ sơ. ( Tạm dừng ngẫu nhiên là phương pháp tôi dựa vào.) Sau đó, nếu bạn có thể thấy hiệu suất sẽ được cải thiện bằng cách đưa vào một thuật toán phức tạp hơn, bằng mọi cách hãy làm như vậy.

Không, bạn nên nghĩ về hiệu suất (đặc biệt là trong việc thiết kế cơ sở dữ liệu) ngay từ đầu. Đã có rất nhiều tác hại đối với ngành công nghiệp của chúng tôi bởi những người nghĩ rằng bất kỳ tối ưu hóa nào cũng là tối ưu hóa sớm. Các trích dẫn được dự định một cách có chủ đích để ngăn chặn mọi người nhìn vào tối ưu hóa vi mô trước khi một vấn đề đã xảy ra. Nó không có ý định không thực hiện bất kỳ tối ưu hóa nào cả. Trong một cơ sở dữ liệu, có nhiều công nghệ được biết là hoạt động kém. Tránh những thứ đó, trong thiết kế, là một phần của những gì bạn cần làm. Rất khó để cấu trúc lại một cơ sở dữ liệu với 100.000.000 bản ghi vì nó được thiết kế bằng cách sử dụng các kỹ thuật đục lỗ kém và chúng tôi không còn có thể tránh được vấn đề bằng cách mua phần cứng tốt hơn.

Lo lắng về tính chính xác ¹ trước, sau đó là khả năng bảo trì, sau đó là an toàn và độ tin cậy, sau đó bạn có thể nghĩ về hiệu suất. Áp dụng thứ tự này cho từng đoạn mã khi bạn đang phát triển nó. Có thể một giải pháp biểu diễn có thể tự nhiên rơi ra chỉ đơn giản là giữ cho mọi thứ rõ ràng và đơn giản.

80% hiệu suất là chọn đúng thuật toán và cấu trúc dữ liệu cho vấn đề; một quicksort được tối ưu hóa kém vẫn đang đánh bại quần của một loại bong bóng được tối ưu hóa cao trong trường hợp trung bình (trường hợp xấu nhất là một trận hòa).

Điều mà tất cả mọi người trên SO đang cố gắng đập bỏ là tư duy "nhanh hơn, ++ p hoặc p ++", nơi mọi người bị cuốn vào việc vượt qua trình biên dịch đến nỗi họ mất dấu vết của vấn đề lớn hơn, dẫn đến mã bị vỡ, lỗi - bị cấm, sai và tốt nhất là không nhanh hơn giải pháp đơn giản hơn. Tôi đã xử lý loại mã đó trực tiếp; một ví dụ rất dễ vỡ đến nỗi chúng tôi không thể thực hiện bất kỳ thay đổi nào mà không phá vỡ nó hoàn toàn.

¹ Trong đó "tính chính xác" có nghĩa là "hoàn thành đặc tả", không đồng nghĩa với "không có lỗi".

Bạn nên bắt đầu suy nghĩ về hiệu suất một khi bạn biết hiệu suất "tốt" là gì. Nói cách khác, sẽ là sai lầm khi bắt đầu suy nghĩ về hiệu suất trước khi bạn xác định các ngưỡng sau đây là gì:

• Hiệu suất không được chấp nhận - sửa chữa nó ngay bây giờ trước khi nó vượt quá tầm tay
• Hiệu suất có thể chấp nhận - đã đến lúc tập trung vào các tính năng khác trước khi bạn cố gắng làm gì nữa với hiệu suất.
• Hiệu suất mục tiêu - số hiệu suất lý tưởng hóa. Tức là nếu bạn có đủ thời gian và nguồn lực, bạn sẽ cần hệ thống của mình để làm gì?

Khi bạn đã xác định các ngưỡng đó là gì, bạn cũng đã xác định được số liệu bạn đang sử dụng để đo lường hiệu suất. Điều đó có nghĩa là bạn có thể thiết lập một số bài kiểm tra hiệu suất tự động mà bạn có thể chạy nhiều lần trong ngày. Điều đó sẽ cho bạn biết nếu bạn đang trở nên tốt hơn hoặc tồi tệ hơn.

Để đưa ra các số liệu đó, bạn cần hiểu hệ thống của bạn cần làm gì. Ví dụ: các số liệu hiệu suất tuyệt đối được gọi cho (phản hồi trong thời gian X) hoặc các phép đo thông lượng được gọi cho (phản hồi X trên mỗi lần Y)? Tối ưu hóa thông lượng và thời gian tuyệt đối đòi hỏi các cách tiếp cận khác nhau và nếu bạn không biết điều gì thực sự quan trọng, bạn có thể tối ưu hóa sai cách.

Có lẽ bạn đã nghe nói rằng tối ưu hóa sớm là gốc rễ của mọi tội lỗi. Câu hỏi là những gì làm cho nó sớm? Theo tôi, không bao giờ là một ý tưởng tồi khi nghĩ về hiệu suất, nhưng đừng quá lo lắng cho đến khi mã của bạn hoạt động. Khi nó hoạt động, thực hiện một số thử nghiệm tải nặng, hồ sơ và xác định các tắc nghẽn và tối ưu hóa hiệu suất của bạn.

Điều đó đang được nói, không có gì sai khi nghĩ về hiệu suất trong giai đoạn mã hóa ban đầu nếu bạn biết một số kỹ thuật sẽ tạo ra sự khác biệt thực sự. Ví dụ: chọn một cấu trúc lưu trữ từ thư viện so với thư viện khác vì kinh nghiệm trong quá khứ đã dạy bạn rằng một trong số chúng nhanh hơn / sử dụng ít RAM hơn so với cái kia. Hoặc xây dựng một cách đơn giản (bạn có thể làm cho nó tinh vi hơn nếu kiểm tra sau này yêu cầu nó) hệ thống bộ nhớ đệm cho dữ liệu mà bạn biếtsẽ được truy cập rất nhiều và sẽ được lưu trữ tốt hơn nhiều. Theo cách này, bạn không băn khoăn quá nhiều về hiệu suất (ít nhất là không phải ban đầu) nhưng bạn đang sử dụng các mẹo và mẹo bạn đã học được từ các dự án khác. Cố gắng giữ những điều đơn giản này để chúng dễ dàng đưa vào trong quá trình phát triển ban đầu và cũng có thể mang lại một số lợi ích.

Hiệu suất phải được chi tiết trong các thông số kỹ thuật liên quan đến hệ thống và người dùng của Tài liệu yêu cầu của bạn. Tôi biết nhiều người chế nhạo ý tưởng thực hiện Phân tích yêu cầu trong quá trình phát triển ứng dụng, nhưng đáng ngạc nhiên là một tài liệu như vậy sẽ trả lời chính xác những gì và nơi bạn nên dành tài nguyên liên quan đến hiệu suất của mình khi ứng dụng sắp hoàn thành. Và nó sẽ trả lời câu hỏi đó một cách kịp thời

Yêu cầu Tài liệu sẽ giúp bạn tiết kiệm hàng trăm giờ thời gian mà nếu không sẽ bị lãng phí cho các quy trình không thiết yếu.

Một cách tiếp cận cân bằng sẽ tốt hơn. Hiệu suất là quan trọng nhưng không quan trọng bằng việc hoàn thành công việc, vì vậy:

1. trước tiên hãy xây dựng một tính năng cố gắng suy nghĩ một chút về những gì bạn đang làm và cách bạn thực hiện nó (sử dụng một ít thời gian suy nghĩ về hiệu suất nhưng không nhiều)
2. Kiểm tra nó
3. một lần đang chạy bắt đầu suy nghĩ xem có nhu cầu thực sự để làm cho nó tốt hơn không (nói chung là bạn sẽ không, nhưng trong một số trường hợp bạn có thể).

Đây là cách tiếp cận phổ biến của tôi để thực hiện so với chức năng và trong các trường hợp chung, tất cả phụ thuộc vào chương trình làm gì và xác minh xem có cần phải làm cho mọi thứ hoạt động tốt hơn không và tôi sẽ tốn bao nhiêu thời gian.

Hãy nghĩ về một trang web Q & A như trang này, tôi nghĩ rằng những người đứng sau nó chắc chắn đã nghĩ rất nhiều về cách đặt câu hỏi và nhận được câu trả lời nhiều nhất về thời gian / chi phí nhất có thể. Nhưng, khi suy nghĩ về thông báo, thực sự không có vấn đề gì nhiều nếu thông báo xuất hiện một lần và cho bạn biết có câu trả lời mới hoặc điều gì đó.

Có một cách để trì hoãn suy nghĩ an toàn về hiệu suất: sử dụng các ngôn ngữ cụ thể theo miền bất cứ nơi nào có thể.

Nếu hầu hết sự phát triển của bạn có thể được thực hiện với DSL nhỏ của riêng bạn và chúng được thiết kế đủ tốt để thể hiện miền vấn đề của bạn ở dạng chung và cấp cao nhất, có thể lấy nguyên mẫu hoạt động trước mà không cần suy nghĩ về hiệu suất và sau đó chỉ cải thiện việc triển khai DSL của bạn chứ không phải mã miền có vấn đề thực tế.

Đó là một cách tiếp cận tốt hơn nhiều từ một điểm duy trì của veiw là tốt.

Bạn nên tính đến hiệu suất. Tuy nhiên, bạn phải vẽ một đường để đánh dấu sự kết thúc điều chỉnh, vì (thông thường) thời gian của bạn quan trọng hơn thời gian của máy tính.

Một bài viết thực sự tốt về hiệu suất là: Trò chơi Shell Performance Performance .

Trò chơi shell hiệu năng máy tính, còn được gọi là "tìm nút thắt cổ chai", luôn được chơi giữa bốn tài nguyên này:

• CPU
• Đĩa
• Mạng
• Ký ức

Tại bất kỳ thời điểm nào, máy tính của bạn đang chờ một số thao tác hoàn tất trên một trong những tài nguyên này. Nhưng cái nào: CPU, bộ nhớ, đĩa hoặc mạng? Nếu bạn quan tâm đến hiệu suất, điều đầu tiên tuyệt đối bạn phải làm là xác định xem những tắc nghẽn nào hiện đang cản trở hiệu suất - và loại bỏ nó.

Cách "tốt nhất" là một thuật ngữ rất tải và câu trả lời có thể phụ thuộc nhiều vào các yếu tố không được biết cho đến khi chạy.

• Bạn có nhiều bộ nhớ không? - bạn sẽ có hiệu suất tốt hơn với cấu trúc dữ liệu "tất cả trong bộ nhớ", nhưng nếu bạn không có đủ bộ nhớ hoán đổi sẽ giết chết hiệu suất của bạn.
• Bạn có cần kiên trì? Một cơ sở dữ liệu cung cấp tính toàn vẹn nhưng chậm hơn cấu trúc dữ liệu "tất cả trong bộ nhớ" ở trên. NHIỀU chậm hơn.
• Bạn có thể lưu trữ kết quả? Varnish có thể giúp với điều đó! http://www.varnish-cache.org/

Danh sách đi và về.

Những gì bạn có thể làm, là để viết "những điều đơn giản nhất mà có thể có thể làm việc" từ những kiến thức bạn đang làm có, và làm điều đó trong một mô-đun thời trang vì vậy bạn có thể dễ dàng sắp xếp lại khi bạn biết thêm. Lưu ý rằng điều "đơn giản nhất" không nhất thiết là đơn giản!

Đó luôn là điều bạn nên ghi nhớ. Tôi nghĩ điều mà hầu hết mọi người đang cố gắng nói là không có nhiều thời gian trong hai ngày cố gắng tối ưu hóa thứ gì đó mà bạn thậm chí không biết là đã bị hỏng. Khi bạn có một sản phẩm đang chạy và có thể thực hiện một số thử nghiệm khả năng sử dụng, điều đó sẽ cho bạn thấy bạn đang gặp vấn đề về hiệu suất. Sau đó, khi bạn có thể xác định các vấn đề hiệu suất thực sự, bạn có thể nhắm mục tiêu tối ưu hóa bạn cần thực hiện.

Về lý thuyết ít nhất, bạn nên bắt đầu suy nghĩ về hiệu suất một khi bạn đang thử nghiệm beta chứ không phải trước đó.

Tuy nhiên, đây không phải là giấy phép để đưa ra quyết định thiết kế kém. Ví dụ: sử dụng chuỗi NVARCHAR làm khóa chính là đường dẫn chắc chắn đến hiệu suất kém; Điều đó nói rằng, đó là một thói quen bẩn thỉu bất kể vấn đề hiệu suất và bạn không nên sử dụng ở nơi đầu tiên.

Nếu thiết kế của bạn tuân theo các thực tiễn tốt nhất thông thường (mọi thứ ở dạng bình thường thứ 3, thông tin phù hợp ẩn trong các lớp của bạn, sử dụng tối thiểu các singletons, v.v.) và có vấn đề về hiệu suất sau này, thì sẽ dễ dàng xử lý (tạo chỉ mục tại đây, thực hiện một bộ đệm ở đó).

HTH

Nó phụ thuộc. Rất hữu ích khi ghi nhớ quy tắc 80/20: hầu hết (giả sử 80%) mã trong ứng dụng sẽ không bao giờ được thực thi thường xuyên đủ để tạo ra bất kỳ sự khác biệt đáng chú ý nào về hiệu suất. Bạn cần tập trung vào 20% còn lại trong đó ứng dụng bị ràng buộc dành khoảng 80% thời gian thực hiện.

Bạn có thể xác định trước một số điểm nóng hiệu suất rõ ràng, chẳng hạn như nếu bạn biết rằng một phép tính cụ thể sẽ được lặp đi lặp lại hàng triệu lần. Trong những trường hợp như vậy, chắc chắn đáng suy nghĩ về việc tối ưu hóa nó lên phía trước bằng cách chọn các cấu trúc dữ liệu và thuật toán phù hợp cho công việc.

Tuy nhiên, tối ưu hóa đó là một hoạt động thiết kế nhiều hơn. Điều thường không có giá trị là tối ưu hóa vi mô, trong đó ai đó dành một lượng thời gian không đáng có bằng các thủ thuật xử lý bit thông minh nhân danh "đạt được hiệu suất". Đặc biệt nếu được thực hiện mà không có các phép đo phù hợp trước và sau, những thay đổi như vậy có thể không tạo ra bất kỳ sự khác biệt nào, hoặc thực sự làm chậm ứng dụng trong hoàn cảnh thực tế.

Nó phụ thuộc vào giai đoạn phát triển của bạn

1) Nếu bạn xây dựng chức năng của phần mềm, hãy tiếp tục và đảm bảo rằng nó hoạt động tốt (nghĩa là mong muốn và hiệu quả).

2) Khi các khối xây dựng được tích hợp, bạn sẽ nhận được gợi ý về trình duyệt tài nguyên, ở đó bạn có chỗ để tối ưu hóa.

Nếu bạn phải bắt đầu suy nghĩ về hiệu suất, bạn sẽ gặp rắc rối. Bạn nên suy nghĩ về hiệu suất tất cả các thời gian. Trên thực tế, tôi nghi ngờ các lập trình viên giỏi sẽ nghĩ về hiệu suất ngay cả khi họ không có ý định, trong một «đàn ông nghĩ về tình dục cứ sau bảy giây».

Điều quan trọng là những hành động bạn sẽ thực hiện dựa trên tất cả những suy nghĩ đó. Suy nghĩ là rẻ, nhưng hành động có thể phá vỡ mã và thổi thời hạn.

Hầu hết thời gian, hành động hợp lý duy nhất sẽ không làm gì cả: bạn đã xác định rằng đoạn mã của bạn sẽ không được gọi thường xuyên đủ để các vấn đề về hiệu năng có thể quan sát được. Có lẽ đó là một đoạn mã khởi động chạy một lần trên mỗi máy tính cho 1% cơ sở người dùng tiềm năng của bạn, có thể đó là một chút mã máy chủ dự phòng bị nhấn chìm trong một biển truy cập cơ sở dữ liệu chậm, có thể đó chỉ là một phép gán số nguyên trong một phần mã không quan trọng.

Rất thường xuyên, bạn nghi ngờ rằng một hoạt động nhất định có thể gây ra vấn đề hiệu suất có thể được giải quyết bằng một thay đổi đơn giản. Chẳng hạn, cảm giác dai dẳng khi chạy một truy vấn SQL phức tạp trên mỗi yêu cầu hoặc yêu cầu cho cùng một dữ liệu từ từ điển hai lần, sẽ rất tệ cho bạn. Đây là nơi kiến ​​thức về các kỹ thuật tối ưu hóa có ích, và có lẽ kết luận đáng ngạc nhiên nhất xảy ra:

Nếu bạn biết về một kỹ thuật nhanh chóng gần như chắc chắn sẽ cải thiện hiệu suất của một đoạn mã, đừng làm điều đó.

Nếu bạn có thể nghĩ về nó bây giờ, bạn chắc chắn có thể làm điều đó trong năm phút sau. Giữ nó ra khỏi mã (nhưng, có lẽ, trong một// TODO bình luận) để lại trình dọn dẹp mã và giúp bạn tiết kiệm thời gian trước đó để làm việc với một tính năng khác, trong khi không lãng phí thời gian nếu bạn kết thúc việc ném mã đó sau đó. Nếu mã ban đầu không gây ra vấn đề về hiệu năng khi được kiểm tra, hãy quay lại và áp dụng kỹ thuật nhanh của bạn.

Tôi không nói ở đây rằng bạn nên tránh viết mã đó là thành ngữ chỉ vì nó xảy ra nhanh hơn. Viết mã thành ngữ theo các thực tiễn tốt nhất để cải thiện năng suất và khả năng đọc và giảm lỗi. Chỉ là nếu bạn có sự lựa chọn giữa mã sách thành ngữ và một thay thế nhanh hơn nhưng dễ viết, hãy luôn tìm kiếm sự dễ đọc thay vì tốc độ.

Tình huống khó khăn duy nhất là khi dường như không có cách nào dễ dàng để cải thiện hiệu suất mã, và rõ ràng là một đoạn mã sẽ bị phá vỡ ngay khi nó gửi cho một cơ sở dữ liệu đầy đủ trên mỗi lần nhấp, hàng trăm yêu cầu SQL trên mỗi trang trên trang web, hoặc bất cứ điều gì tương tự khủng khiếp. Đây là nơi bạn thực sự cần dừng lại và suy nghĩ thêm. Đây thường là những vấn đề kiến ​​trúc không thể giải quyết trên quy mô địa phương. Xác nhận sự nghi ngờ của bạn bằng một đột biến hoặc nguyên mẫu nhanh chóng, tìm kiếm các trải nghiệm tương tự và các giải pháp phổ biến và xem xét thay đổi kiến ​​trúc hoặc giảm tính năng.

IMHO điều quan trọng là phải suy nghĩ về hiệu suất trước khi bạn triển khai hệ thống, nhưng chỉ nghĩ về. Bạn nên phân tích ứng dụng và tìm hiểu những gì có thể là nút cổ chai hiệu năng tiềm năng.

Sau đó thực hiện hệ thống càng đơn giản càng tốt. Nếu vấn đề hiệu suất phát sinh, sau đó tối ưu hóa.

Ví dụ: giả sử bạn có máy khách GUI nhận dữ liệu thông qua một số loại dịch vụ (SOAP, REST HTTP, v.v.). Sau đó, điều quan trọng nhất đối với hiệu suất / khả năng mở rộng cao là có càng ít cuộc gọi càng tốt, mỗi cuộc gọi trả về rất nhiều dữ liệu, thay vào đó là rất nhiều cuộc gọi trả lại một ít thông tin cho mỗi cuộc gọi, ví dụ như giao tiếp chunky với trò chuyện.

Khi triển khai loại hệ thống này, tôi sẽ không quan tâm nhiều đến số lượng cuộc gọi giữa hệ thống. Nhưng tôi sẽ đảm bảo rằng cơ sở mã sẽ giúp tôi dễ dàng cấu trúc lại / tối ưu hóa khi có nhu cầu.

Bạn nên suy nghĩ về hiệu suất theo những cách rất chung từ đầu. Bạn nên chọn cấu trúc dữ liệu và thuật toán sẽ hoạt động tốt cho ứng dụng của bạn và có hiệu quả hợp lý. Các thuật toán là nền tảng cho phần mềm và cấu trúc dữ liệu cũng vậy. Bạn có thể sẽ phải viết lại chính nếu bạn cần thực hiện các thay đổi lớn cho một trong hai, trong khi các chi tiết nhỏ hơn có thể được viết lại dễ dàng hơn.

Bạn cũng có thể muốn có được những thói quen hiệu quả, nhưng những điều này sẽ phụ thuộc vào ngôn ngữ. Trong C ++, ví dụ: "++ i;" như một tuyên bố hoặc biểu thức độc lập luôn ít nhất là tốt như "i ++;" và có khả năng hiệu quả hơn nhiều. Tuy nhiên, trong hầu hết các trường hợp, bạn nên viết mã rõ ràng và tin tưởng vào trình biên dịch. Tập thói quen lo lắng về hiệu quả vi mô gần như chắc chắn sẽ gây ra cho bạn nhiều vấn đề hơn nó giải quyết. Đối với các ứng dụng dành cho máy tính để bàn, trình biên dịch ít nhất cũng thông minh như bạn nói về những thứ như i >> 1vs.i / 2 , hoặc cách tốt nhất để cải thiện hiệu suất là có được trình biên dịch tốt hơn, vì vậy đừng lo lắng về điều đó.

Ngoài ra, đừng lo lắng nhiều cho đến khi bạn có thứ gì đó bạn có thể kiểm tra. Vào thời điểm đó, bạn có thể lập hồ sơ chương trình để xem các điểm nóng ở đâu, và có thể có ý tưởng về việc bạn có chương trình hiệu suất hay không. Nếu bạn cần cải thiện hiệu suất, hãy tìm nơi chương trình dành phần lớn thời gian và cải thiện mọi thứ ở đó. Nếu bạn đã thiết kế đủ hiệu quả toàn cầu và viết chương trình tốt, bạn chỉ thay đổi một phần tương đối nhỏ của chương trình.

Tôi nghĩ điều tốt nhất bạn có thể làm là tuân theo các thực tiễn thiết kế tốt (ví dụ: đừng làm những việc bạn biết sẽ cản trở hiệu suất) cho đến khi bạn làm việc gì đó. Nếu bạn không thể đo lường sự cải thiện, bạn không thể cải thiện. Khi bạn đã có thứ gì đó bạn có thể thử nghiệm, thì đó thường là một ý tưởng hay để chạy thử và tìm hiểu ý tưởng về các điểm nóng (nếu có). Nếu có thứ gì đó nhảy ra khỏi bạn, bạn nên xem xét tái cấu trúc hoặc viết lại khu vực có vấn đề, nhưng nếu nó không quá tệ (chỉ vì mã dành 90% thời gian của nó trong hai hoặc ba phương thức không có nghĩa gì nếu nó thực hiện đầy đủ tổng thể) sau đó cứ tiếp tục phát triển Một cái gì đó tôi đã thấy hơn một lần là các nhà phát triển dành nhiều ngày để tối ưu hóa phần phức tạp nhất của hệ thống,

Khi nào tôi nên bắt đầu nghĩ về nó? Tôi nên bỏ ra bao nhiêu nỗ lực? Điều đó phụ thuộc vào Thang điểm của Burnburn của dự án. (Nói cách khác, nguy cơ không có hiệu suất tốt là gì?)

Tìm hiểu các nguyên tắc cơ bản trước (xem câu trả lời của Robert Harvey ). Để áp dụng tư duy định hướng hiệu suất trong các giai đoạn phát triển phần mềm khác nhau, nhà phát triển phải biết từ trong ra ngoài, để quá trình suy nghĩ sẽ không bị cản trở bởi những cân nhắc thêm đó. (Nói cách khác, bắt đầu suy nghĩ về hiệu suất trước khi dự án được hình thành.)

Trong giai đoạn đầu phát triển, hãy sử dụng tự do các công cụ định hình hiệu suất và theo dõi lịch sử thống kê. Đặc biệt chú ý đến việc tổ chức các thông tin đó để làm cho chúng hữu ích cho việc ra quyết định sau này.

Sau đó, tùy thuộc vào bản chất dự án của bạn và Quy mô Cockburn của nó:

• Tạo mẫu nhanh, hoặc "nổ ra mã như không có ngày mai", hoặc phát triển nội bộ với tác động kinh doanh thấp: chỉ cần giữ số liệu thống kê. Đừng nghĩ về hiệu suất chưa. Thực hiện chức năng một cách dễ dàng nhất. Gắn bó với thuật toán đầu tiên xuất hiện trong tâm trí của bạn.

  • Ở nửa sau của dự án, sẽ có thử nghiệm hiệu năng đặc biệt để xác định "điểm nóng" dựa trên các trường hợp sử dụng thực tế. Nếu có bất kỳ vấn đề nào về hiệu năng làm cho phần mềm không thể sử dụng được, nó có thể dễ dàng được nhận dạng.
  • Để phát triển nội bộ với tác động kinh doanh thấp, chỉ cần triển khai mã và khắc phục các sự cố về hiệu suất sau này.

• Các ứng dụng máy tính để bàn, đòi hỏi một cách tiếp cận nhất quán, toàn diện về hiệu suất. Nó không phải được tối ưu hóa cao; tuy nhiên, nên có càng ít "treo" (không phản hồi) càng tốt.

  • Các ứng dụng máy tính để bàn thường có đường dẫn thực thi rất phức tạp, làm phức tạp suy nghĩ theo định hướng hiệu suất. Thiết kế lớp sẽ cho phép tách các vấn đề về hiệu suất Cơ sở dữ liệu / Mạng khỏi các vấn đề về hiệu suất GUI, được xử lý bởi các chuyên gia khác nhau trong nhóm của bạn.
  • Một lịch sử của dấu vết Log sẽ cho phép các điểm nóng được xác định.

• Điện toán hiệu năng cao, đòi hỏi phải có hiệu năng cao nhất từ ​​phần cứng.

  • Chỉ định ai đó trong nhóm của bạn chịu trách nhiệm phân tích và báo cáo số liệu thống kê hiệu suất.
  • Đưa ra các lý thuyết về các đặc tính hiệu suất, xác minh bằng các thử nghiệm và so sánh với các dự đoán của bạn từ các mô hình Comp Sci được đơn giản hóa.
  *

Lúc bắt đầu. Xác định các đặc tính hiệu suất cần thiết. Nếu bạn không thể xác định mục tiêu, bạn cần phải lùi lại để hiểu rõ hơn các yêu cầu của bạn hoặc trì hoãn cho đến khi bạn biết các yêu cầu thành phần của mình với rủi ro bạn có thể viết lại. Sau đó, kiểm tra. Đừng tối ưu hóa, kiểm tra. Nếu bạn mã không kiểm tra hiệu suất, tối ưu hóa. Với một khung kiểm tra tại chỗ, việc sử dụng các công cụ giám sát hiệu suất hiện có sẽ giúp công việc trở nên dễ dàng hợp lý.

Giữ các bài kiểm tra hiệu suất trong suốt vòng đời của dự án dưới dạng kiểm tra hồi quy. Mã bảo trì nổi tiếng với việc kích hoạt các vấn đề về hiệu năng vì 'các bản sửa lỗi' thường có trọng tâm rất hẹp.

Tôi luôn dựa vào một công thức đơn giản:

1. Lam cho no hoạt động
2. Làm cho đúng
3. Làm nhanh

... Theo thứ tự đó.

Theo c2 , công thức này được quy cho Kent Beck .