Performance Analysis and Tuning on Modern CPUs Part 1

Posted Aug 6, 2025

By Khoi Nguyen Van

22 min read

Giới thiệu

Người ta thường nói, “hiệu năng là vua”. Điều này đúng cách đây một thập kỷ và hiện tại vẫn còn nguyên giá trị. Theo [Dom, 2017], vào năm 2017, thế giới đã tạo ra 2,5 triệu tỷ (quintillion) byte dữ liệu mỗi ngày, và như dự đoán trong [Sta, 2018], con số này đang tăng trưởng 25% mỗi năm. Trong thế giới ngày càng lấy dữ liệu làm trung tâm, sự phát triển của trao đổi thông tin thúc đẩy nhu cầu về cả phần mềm (SW) nhanh hơn và phần cứng (HW) nhanh hơn. Có thể nói, sự tăng trưởng dữ liệu đặt ra yêu cầu không chỉ về sức mạnh tính toán mà còn về hệ thống lưu trữ và mạng.

Trong kỷ nguyên PC, các nhà phát triển thường lập trình trực tiếp trên hệ điều hành, có thể chỉ thông qua một vài thư viện. Khi thế giới chuyển sang kỷ nguyên điện toán đám mây, ngăn xếp phần mềm trở nên sâu hơn và phức tạp hơn. Lớp trên cùng của ngăn xếp mà hầu hết các nhà phát triển làm việc đã ngày càng cách xa phần cứng. Những lớp bổ sung này che giấu phần cứng thực tế, cho phép sử dụng các loại bộ tăng tốc mới cho các khối lượng công việc mới nổi. Tuy nhiên, mặt trái của sự phát triển này là các nhà phát triển ứng dụng hiện đại ngày càng ít quan tâm tới phần cứng mà phần mềm của họ đang chạy.

Trong nhiều thập kỷ, các lập trình viên phần mềm đã có một “cuộc sống dễ dàng” nhờ định luật Moore. Đã từng có trường hợp một số nhà cung cấp phần mềm chỉ chờ thế hệ phần cứng mới để tăng tốc ứng dụng mà không dành nguồn lực con người để cải thiện mã nguồn. Khi xem Hình 1, ta có thể nhận thấy tốc độ phát triển hiệu năng đơn luồng đang chậm lại.

Hình 1: Dữ liệu xu hướng vi xử lý trong 40 năm. © Hình ảnh bởi K. Rupp thông qua karlrupp.net

Khi mà mỗi thế hệ phần cứng không còn mang lại sự cải thiện hiệu năng đáng kể [Leiserson et al., 2020], chúng ta phải chú ý nhiều hơn đến tốc độ chạy của mã nguồn.

Tại sao chúng ta vẫn cần tối ưu hiệu năng?

Khi tìm cách cải thiện hiệu năng, các nhà phát triển không nên dựa vào phần cứng. Thay vào đó, họ nên bắt đầu tối ưu hóa mã nguồn ứng dụng của mình.

“Phần mềm ngày nay cực kỳ kém hiệu quả; đã đến thời điểm các lập trình viên phần mềm thật sự giỏi tối ưu hóa.”
— Marc Andreessen, doanh nhân và nhà đầu tư Mỹ (a16z Podcast, 2020)

Kinh nghiệm cá nhân:
Khi làm việc tại Intel, tôi thường nghe lặp lại một câu chuyện: khi khách hàng Intel gặp sự chậm chạp trong ứng dụng, họ ngay lập tức và vô thức đổ lỗi cho Intel có CPU chậm. Nhưng khi Intel cử chuyên gia tối ưu hiệu năng đến giúp cải thiện ứng dụng, không hiếm trường hợp ứng dụng được tăng tốc lên 5 lần, thậm chí 10 lần.

Đạt được hiệu năng cao là một thách thức và thường đòi hỏi nỗ lực lớn, nhưng hy vọng cuốn sách này sẽ cung cấp cho bạn công cụ để đạt được điều đó.

Các CPU hiện đại ngày càng có nhiều lõi hơn mỗi năm. Tính tới cuối năm 2019, bạn có thể mua bộ xử lý máy chủ cao cấp có hơn 100 lõi logic. Điều này rất ấn tượng, nhưng không có nghĩa là chúng ta không cần quan tâm đến hiệu năng nữa. Thường thì hiệu năng ứng dụng không được cải thiện dù có thêm nhiều lõi CPU. Hiệu năng của ứng dụng đa luồng thông thường không phải lúc nào cũng tỷ lệ thuận với số lõi CPU được cấp cho tác vụ. Việc hiểu lý do tại sao điều này xảy ra và các cách khắc phục là rất quan trọng cho sự phát triển sản phẩm. Không thực hiện phân tích và tối ưu hiệu năng đúng có thể bỏ lỡ rất nhiều hiệu năng và tiền bạc, thậm chí khiến sản phẩm thất bại.

Theo [Leiserson et al., 2020], ít nhất trong ngắn hạn, phần lớn lợi ích hiệu năng cho các ứng dụng sẽ đến từ ngăn xếp phần mềm. Đáng buồn là các ứng dụng không đạt hiệu năng tối ưu mặc định. Bài báo [Leiserson et al., 2020] cũng cung cấp ví dụ tuyệt vời về tiềm năng cải thiện hiệu năng ở cấp độ mã nguồn. Việc tối ưu hóa chương trình nhân hai ma trận 4096x4096 cho kết quả tăng tốc trên 60.000 lần. Lý do đưa ra ví dụ này không phải chỉ trích Python hay Java (đều là ngôn ngữ tuyệt vời), mà để phá vỡ quan niệm phần mềm “mặc định đã đủ nhanh”.

Bảng 1: Tăng tốc từ kỹ thuật tối ưu hiệu năng đối với chương trình nhân hai ma trận 4096x4096 chạy trên hệ thống Intel Xeon E5-2666 v3 hai socket với tổng cộng 60 GB RAM. Theo [Leiserson et al., 2020].

Phiên bản	Triển khai	Tăng tốc tuyệt đối	Tăng tốc tương đối
1	Python	1	—
2	Java	11	10.8
3	C	47	4.4
4	Vòng lặp song song	366	7.8
5	Phân chia và chinh phục song song	6.727	18.4
6	Vector hóa	23.224	3.5
7	AVX intrinsics	62.806	2.7

Dưới đây là một số yếu tố quan trọng khiến hệ thống không tự đạt hiệu năng tối ưu:

Giới hạn của CPU: Rất dễ đặt câu hỏi: “Tại sao phần cứng không giải quyết mọi vấn đề?” Các CPU hiện đại thực thi lệnh rất nhanh và ngày càng tốt hơn qua mỗi thế hệ. Nhưng chúng không thể làm gì nhiều nếu các lệnh thực hiện công việc không tối ưu hoặc dư thừa. Bộ xử lý không thể tự động biến mã nguồn chưa tối ưu thành mã chạy nhanh hơn. Ví dụ, nếu ta cài đặt thuật toán sắp xếp bằng BubbleSort, CPU sẽ không nhận ra và thay thế nó bằng QuickSort mà chỉ đơn giản thực thi những gì được yêu cầu.
Giới hạn của trình biên dịch: “Chẳng phải trình biên dịch phải giải quyết mọi vấn đề sao?” Đúng là các trình biên dịch ngày nay rất thông minh, nhưng vẫn có thể tạo ra mã không tối ưu. Trình biên dịch giỏi loại bỏ việc thừa, nhưng khi đưa ra quyết định phức tạp như inlining hàm, mở rộng vòng lặp…, chúng có thể không tạo ra mã tốt nhất. Ví dụ, không có câu trả lời “có/không” rõ ràng cho việc trình biên dịch có nên luôn inline một hàm không. Quyết định này thường dựa vào nhiều yếu tố mà trình biên dịch phải cân nhắc. Thường thì trình biên dịch dựa vào mô hình chi phí và các heuristics phức tạp, mà không phải lúc nào cũng phù hợp mọi trường hợp. Ngoài ra, trình biên dịch chỉ tối ưu hóa khi chắc chắn là an toàn và không ảnh hưởng tới độ đúng của mã máy. Điều này khiến các nhà phát triển biên dịch phải thận trọng và thường bỏ qua một số tối ưu hóa. Cuối cùng, trình biên dịch thường không thay đổi cấu trúc dữ liệu của chương trình, trong khi đây cũng là yếu tố quan trọng với hiệu năng.
Giới hạn của phân tích độ phức tạp thuật toán: Các nhà phát triển thường quá tập trung vào phân tích độ phức tạp thuật toán và chọn thuật toán phổ biến với độ phức tạp tối ưu, dù nó không phải là hiệu quả nhất cho bài toán cụ thể. So sánh hai thuật toán sắp xếp InsertionSort và QuickSort, rõ ràng QuickSort tốt hơn về Big O ở trường hợp trung bình: InsertionSort là O(N2), QuickSort là O(N log N). Tuy nhiên, với kích thước N nhỏ, InsertionSort lại nhanh hơn QuickSort. Phân tích độ phức tạp không tính hết ảnh hưởng của branch prediction và caching, nên thường gộp chúng vào hằng số C, đôi khi ảnh hưởng lớn đến hiệu năng. Tin tưởng tuyệt đối vào Big O mà không thử nghiệm trên bài toán thực tế có thể dẫn tới quyết định sai. Thuật toán nổi tiếng cho một vấn đề không nhất thiết là nhanh nhất trong thực tế với mọi đầu vào.

Các giới hạn trên tạo cơ hội để tối ưu hiệu năng phần mềm đạt tiềm năng tối đa. Ngăn xếp phần mềm gồm nhiều lớp: firmware, BIOS, OS, thư viện, và mã nguồn ứng dụng. Nhưng phần lớn các lớp dưới không phải do chúng ta kiểm soát trực tiếp, nên trọng tâm sẽ là mã nguồn. Một phần mềm quan trọng khác là trình biên dịch. Có thể đạt được tăng tốc lớn nếu làm cho trình biên dịch sinh mã máy mong muốn bằng các hướng dẫn. Bạn sẽ gặp nhiều ví dụ như vậy trong sách này.

Kinh nghiệm cá nhân:
Để cải thiện ứng dụng, bạn không cần phải là chuyên gia biên dịch. Theo kinh nghiệm, ít nhất 90% chuyển đổi có thể thực hiện ở mức mã nguồn mà không cần can thiệp sâu vào trình biên dịch. Tuy nhiên, hiểu cách trình biên dịch hoạt động và làm chủ nó là lợi thế lớn khi tối ưu hiệu năng.

Ngoài ra, hiện nay quan trọng là tăng khả năng mở rộng của ứng dụng bằng cách phân phối trên nhiều lõi vì hiệu năng đơn luồng ngày càng đạt ngưỡng. Việc này yêu cầu giao tiếp hiệu quả giữa các luồng, loại bỏ tiêu tốn tài nguyên không cần thiết và các vấn đề thường gặp trong chương trình đa luồng.

Hiệu năng không chỉ đến từ tối ưu hóa phần mềm. Theo [Leiserson et al., 2020], hai nguồn tăng tốc lớn khác trong tương lai là thuật toán (nhất là với các lĩnh vực mới như machine learning) và thiết kế phần cứng tối giản. Thuật toán rõ ràng đóng vai trò lớn, nhưng cuốn sách này không đề cập. Chúng ta cũng không bàn về thiết kế phần cứng mới do phần lớn các nhà phát triển phần mềm chỉ làm việc với phần cứng hiện có. Tuy nhiên, hiểu thiết kế CPU hiện đại là cần thiết để tối ưu ứng dụng.

“Sau thời kỳ Moore, việc làm cho mã chạy nhanh và đặc biệt là tối ưu hóa cho phần cứng nó chạy sẽ ngày càng quan trọng.”
— [Leiserson et al., 2020]

Phương pháp trong sách tập trung vào việc tối ưu hiệu năng tối đa từ ứng dụng. Những chuyển đổi này thường thuộc hàng 6 và 7 trong Bảng 1. Các cải tiến này thường nhỏ, không quá 10%. Tuy nhiên, đừng đánh giá thấp ý nghĩa của 10% tăng tốc, đặc biệt với ứng dụng phân tán lớn chạy trên đám mây. Theo [Hennessy, 2018], năm 2018 Google chi số tiền tương đương cho máy chủ chạy đám mây và cho hạ tầng điện/power-làm mát. Hiệu suất năng lượng là vấn đề lớn, có thể cải thiện nhờ tối ưu phần mềm.

“Ở quy mô này, hiểu đặc trưng hiệu năng trở nên quan trọng – ngay cả cải tiến nhỏ về hiệu năng hoặc sử dụng cũng có thể mang lại tiết kiệm chi phí khổng lồ.”
— [Kanev et al., 2015]

Ai cần tối ưu hiệu năng?

Kỹ thuật hiệu năng không cần phải chứng minh nhiều trong các ngành như điện toán hiệu năng cao (HPC), dịch vụ đám mây, giao dịch tần số cao (HFT), phát triển game và các lĩnh vực đòi hỏi hiệu năng. Ví dụ, Google báo cáo rằng tìm kiếm chậm hơn 2% khiến số lượng tìm kiếm giảm 2% mỗi người dùng. Với Yahoo!, tải trang nhanh hơn 400 mili giây làm tăng 5-9% lưu lượng. Trong trò chơi của những con số lớn, cải thiện nhỏ cũng tạo ra ảnh hưởng lớn. Những ví dụ đó cho thấy dịch vụ càng chậm thì càng ít người sử dụng.

Thú vị là, kỹ thuật hiệu năng không chỉ cần thiết ở các lĩnh vực nêu trên. Ngày nay nó cũng cần trong các ứng dụng và dịch vụ phổ thông. Nhiều công cụ chúng ta dùng hàng ngày sẽ không tồn tại nếu không đáp ứng yêu cầu hiệu năng. Ví dụ, tính năng IntelliSense của Visual C++ tích hợp trong Visual Studio IDE có giới hạn hiệu năng rất nghiêm ngặt. Để autocomplete hoạt động, nó phải phân tích toàn bộ codebase trong vài mili giây. Không ai dùng trình soạn thảo mã nguồn nếu mất vài giây để gợi ý autocomplete. Tính năng này phải rất nhạy và trả về kết quả hợp lý khi người dùng nhập mã mới. Thành công của ứng dụng tương tự chỉ đạt được nhờ thiết kế phần mềm chú trọng hiệu năng và kỹ thuật tối ưu hiệu năng hợp lý.

Đôi khi các công cụ nhanh lại được dùng ở lĩnh vực ngoài dự kiến ban đầu. Ví dụ, ngày nay các engine game như Unreal và Unity được sử dụng trong kiến trúc, dựng hình 3D, làm phim… Vì chúng hiệu năng cao, chúng là lựa chọn tự nhiên cho ứng dụng cần render 2D/3D, engine vật lý, phát hiện va chạm, âm thanh, hoạt ảnh…

“Công cụ nhanh không chỉ giúp người dùng làm việc nhanh hơn; chúng còn giúp người dùng giải quyết những loại bài toán mới, theo cách hoàn toàn mới.”
— Nelson Elhage viết trong bài blog (2020).

Hiển nhiên là mọi người đều ghét phần mềm chậm. Đặc trưng hiệu năng có thể là yếu tố duy nhất khiến khách hàng chuyển sang sản phẩm đối thủ. Chú trọng hiệu năng có thể mang lại lợi thế cạnh tranh cho sản phẩm của bạn.

Kỹ thuật tối ưu hiệu năng là công việc quan trọng, nhưng có thể rất tốn thời gian. Thực tế, tối ưu hóa hiệu năng là cuộc chơi không bao giờ kết thúc. Luôn có cái để tối ưu. Cuối cùng, lập trình viên sẽ đạt tới điểm giảm hiệu quả, nơi cải tiến thêm đòi hỏi chi phí kỹ thuật rất lớn mà không đáng với nỗ lực bỏ ra. Từ góc độ đó, biết khi nào dừng tối ưu là khía cạnh quan trọng của công việc hiệu năng. Một số tổ chức đạt được điều này bằng cách tích hợp thông tin vào quy trình review code: các dòng mã được chú thích với chỉ số “cost”. Dựa vào đó, lập trình viên quyết định có nên cải thiện hiệu năng phần nào hay không.

Trước khi bắt đầu tối ưu hiệu năng, hãy đảm bảo bạn có lý do chính đáng. Tối ưu chỉ để tối ưu mà không thêm giá trị là vô ích. Kỹ thuật tối ưu hiệu năng hợp lý bắt đầu bằng mục tiêu hiệu năng rõ ràng, xác định điều bạn muốn đạt được và lý do tại sao. Đồng thời, bạn nên chọn chỉ số để đo lường kết quả. Bạn có thể đọc thêm về đặt mục tiêu hiệu năng trong [Gregg, 2013] và [Akinshin, 2019].

Dù sao, việc thực hành và thành thạo phân tích/tối ưu hiệu năng luôn là điều tuyệt vời. Nếu bạn chọn cuốn sách vì lý do đó, hãy tiếp tục đọc.

Phân tích hiệu năng là gì?

Bạn từng tranh luận với đồng nghiệp về hiệu năng đoạn mã nào đó chưa? Nếu rồi, bạn sẽ biết thật khó để dự đoán đoạn mã nào chạy nhanh nhất. Có quá nhiều yếu tố trong vi xử lý hiện đại, chỉ một thay đổi nhỏ cũng có thể gây biến động lớn về hiệu năng. Vì thế, lời khuyên đầu tiên của sách này là: Luôn đo lường.

Kinh nghiệm cá nhân:
Tôi thấy nhiều người dựa vào trực giác khi tối ưu ứng dụng. Thường thì kết quả chỉ là sửa ngẫu nhiên chỗ này chỗ kia mà không cải thiện thực sự hiệu năng.

Lập trình viên thiếu kinh nghiệm thường sửa mã nguồn và hy vọng chương trình sẽ chạy nhanh hơn. Ví dụ như thay thế i++ bằng ++i khắp nơi, nghĩ rằng giá trị trước đó của i không dùng nữa. Thực tế, thay đổi này thường không ảnh hưởng gì tới mã sinh ra vì trình biên dịch tối ưu sẽ nhận ra và loại bỏ bản sao thừa. Nhiều mẹo tối ưu nhỏ từng đúng trong quá khứ, nhưng trình biên dịch hiện đại đã biết hết. Ngoài ra, nhiều người lạm dụng các mẹo bit-twiddling cũ, như dùng hoán vị XOR, trong khi thực tế std::swap lại sinh mã nhanh hơn. Những thay đổi ngẫu nhiên này gần như không cải thiện hiệu năng. Tìm đúng chỗ để sửa phải là kết quả của phân tích hiệu năng cẩn thận, không phải trực giác hay đoán mò.

Có nhiều phương pháp phân tích hiệu năng có thể giúp bạn khám phá vấn đề. Các phương pháp phân tích đặc thù CPU trong sách này đều có điểm chung: chúng dựa vào việc thu thập thông tin về cách chương trình thực thi. Mọi thay đổi trong mã nguồn đều phải dựa trên việc phân tích và diễn giải dữ liệu thu thập được.

Tìm ra nút thắt hiệu năng chỉ là một nửa công việc kỹ sư. Nửa còn lại là sửa nó đúng cách. Đôi khi chỉ cần thay đổi một dòng mã cũng làm hiệu năng tăng vọt. Phân tích và tối ưu hiệu năng là tìm và sửa đúng dòng đó. Bỏ lỡ cơ hội như vậy là lãng phí lớn.

Sách này bàn về những gì?

Cuốn sách này được viết nhằm giúp các nhà phát triển hiểu rõ hơn về hiệu năng ứng dụng, học cách tìm ra các điểm chưa tối ưu và loại bỏ chúng.
Tại sao chương trình nén tôi tự viết lại chậm gấp đôi so với chương trình thông thường? Tại sao sửa một hàm lại khiến hiệu năng giảm một nửa? Khách hàng than phiền ứng dụng chậm, tôi không biết bắt đầu từ đâu? Tôi đã tối ưu chương trình hết mức chưa? Làm gì với các lần cache miss và branch misprediction? Hy vọng sau khi đọc sách, bạn sẽ trả lời được những câu hỏi đó.

Nội dung sách gồm:

Chương 2: Làm thế nào để thực hiện thử nghiệm hiệu năng công bằng và phân tích kết quả. Giới thiệu thực hành tốt trong kiểm thử và so sánh hiệu năng.
Chương 3, 4: Kiến thức cơ bản về vi kiến trúc CPU và thuật ngữ phân tích hiệu năng; nếu biết rồi có thể bỏ qua.
Chương 5: Các phương pháp phổ biến nhất để phân tích hiệu năng; giải thích cách kỹ thuật profiling hoạt động và dữ liệu có thể thu thập.
Chương 6: Thông tin về các tính năng của CPU hiện đại hỗ trợ và nâng cao phân tích hiệu năng. Trình bày cách hoạt động và giải quyết vấn đề.
Chương 7-9: Công thức cho các vấn đề hiệu năng điển hình, tổ chức thuận tiện để dùng với Top-Down Microarchitecture Analysis (xem mục 6.1), một trong những khái niệm quan trọng nhất của sách.
Chương 10: Các chủ đề tối ưu hóa không thuộc nhóm nào ở ba chương trước nhưng vẫn đủ quan trọng để có mặt trong sách.
Chương 11: Kỹ thuật phân tích ứng dụng đa luồng. Trình bày các thách thức lớn nhất khi tối ưu hiệu năng ứng dụng đa luồng và các công cụ phân tích. Chủ đề này lớn nên chương chỉ tập trung vào các vấn đề phần cứng, như “False Sharing”.

Ví dụ trong sách chủ yếu dựa trên phần mềm mã nguồn mở: Hệ điều hành Linux, trình biên dịch Clang dựa trên LLVM cho ngôn ngữ C/C++, và công cụ profiling Linux perf. Lý do chọn các công nghệ này không chỉ là vì chúng phổ biến, mà còn vì mã nguồn mở giúp hiểu rõ cơ chế hoạt động. Điều này đặc biệt hữu ích khi học các khái niệm trong sách. Thỉnh thoảng sẽ giới thiệu công cụ độc quyền lớn như Intel VTune Profiler.

Sách này không bàn về gì?

Hiệu năng hệ thống phụ thuộc vào nhiều thành phần: CPU, OS, bộ nhớ, thiết bị I/O… Ứng dụng có thể hưởng lợi từ việc tối ưu từng thành phần. Về tổng thể, kỹ sư nên phân tích hiệu năng toàn hệ thống. Tuy nhiên, yếu tố lớn nhất là CPU, nên sách này chủ yếu tập trung vào phân tích hiệu năng từ góc nhìn CPU, đôi khi đề cập tới OS và bộ nhớ.

Phạm vi sách không vượt quá một socket CPU, nên sẽ không bàn về kỹ thuật tối ưu cho hệ phân tán, NUMA, hoặc hệ thống dị thể. Việc offload sang accelerator (GPU, FPGA…) qua OpenCL, OpenMP cũng không đề cập.

Sách này lấy kiến trúc CPU Intel x86 làm trung tâm và không cung cấp công thức tối ưu riêng cho AMD, ARM hay RISC-V. Tuy nhiên, nhiều nguyên tắc trong sách vẫn áp dụng tốt cho các loại chip đó. Linux là hệ điều hành chính trong sách, nhưng phần lớn ví dụ đều có thể áp dụng cho Windows, Mac.

Toàn bộ mã trong sách viết bằng C, C++ hoặc hợp ngữ x86, nhưng ý tưởng có thể áp dụng cho các ngôn ngữ biên dịch ra mã máy như Rust, Go, thậm chí Fortran. Vì sách tập trung vào ứng dụng user-mode gần phần cứng, sẽ không bàn về môi trường quản lý như Java.

Cuối cùng, tác giả giả định người đọc có toàn quyền với phần mềm mình phát triển, bao gồm lựa chọn thư viện và trình biên dịch dùng. Do đó, sách không nói về tối ưu các gói thương mại đã mua sẵn, ví dụ như tối ưu truy vấn SQL.

Tóm tắt chương

Phần cứng không còn mang lại nhiều tăng tốc hiệu năng đơn luồng như những năm trước. Vì vậy tối ưu hiệu năng ngày càng quan trọng so với 40 năm qua. Ngành công nghiệp tính toán đang thay đổi mạnh chưa từng thấy từ thập niên 90.
Theo [Leiserson et al., 2020], tối ưu phần mềm sẽ là động lực chính cho tăng trưởng hiệu năng trong tương lai gần. Không nên đánh giá thấp tầm quan trọng của tối ưu hiệu năng. Với ứng dụng phân tán lớn, từng cải tiến nhỏ đều mang lại tiết kiệm chi phí lớn.
Phần mềm không tự đạt hiệu năng tối ưu mặc định. Có nhiều hạn chế khiến ứng dụng không đạt tiềm năng tối đa. Cả môi trường phần cứng lẫn phần mềm đều có những hạn chế đó. CPU không thể tự tăng tốc cho thuật toán chậm. Trình biên dịch không thể tạo mã tối ưu cho mọi chương trình. Do đặc thù phần cứng, thuật toán tốt nhất về lý thuyết chưa chắc nhanh nhất thực tế. Tất cả điều này tạo ra cơ hội để tối ưu ứng dụng.
Với một số loại ứng dụng, hiệu năng không chỉ là một tính năng. Nó cho phép người dùng giải quyết bài toán mới theo cách mới.
Tối ưu hóa phần mềm cần có lý do kinh doanh rõ ràng. Lập trình viên nên đặt mục tiêu định lượng và chỉ số đo lường tiến độ.
Dự đoán hiệu năng đoạn mã là gần như không thể vì có quá nhiều yếu tố ảnh hưởng trên nền tảng hiện đại. Khi tối ưu phần mềm, lập trình viên không nên dựa vào trực giác mà phải dùng phân tích hiệu năng cẩn thận.

Books

sharing

This post is licensed under CC BY 4.0 by the author.