Nhái Cốm Blog

I love you just the way you are

0R8A4000_

Vài yếu tố liên quan đến hiệu năng

Leave a comment

Tác giả: Rico Mariani
Bài gốc: Performance Tidbits

Lược dịch

Delegate

Bạn có sử dụng delegate khi bạn có thể thay thế bằng tính đa hình? Delegate cho phép bạn gọi bất kì phương thức trên bất kì đối tượng nào. Chỉ với một interface hoặc một phương thức ảo (virtual method), bạn cũng có thể có một hàm xác định trên mọi đối tượng và điều này thông thường là đủ. Delegate cần tài nguyên cho từng đối tượng trong bộ nhớ trong khi các các phương thức ảo chỉ sử dụng tài nguyên đối với từng class.

Virtual Method (phương thức ảo)

Bạn có sử dụng phương thức ảo khi bạn hoàn toàn có thể sử dụng một lời gọi trực tiếp đến phương thức? Rất nhiều trường hợp lập trình viên sử dụng phương thức ảo nhằm tăng khả năng mở rộng trong tương lai. Đây là một điều tốt nhưng cái gì cũng có giá của nó. Vì vậy bạn cần chắc chắn rằng việc sử dụng phương thức ảo là bắt buộc để giúp bạn thực hiện điều mình muốn. Đôi khi mọi người chỉ nghĩ đến các vấn đề gọi phương thức mà không cân nhắc đến việc làm thế nào “các đối tượng mở rộng” được tạo ra. Để rồi sau đó họ nhận ra rằng phần lớn các phương thức ảo chẳng giúp ích gì; họ buộc phải tạo ra một mô hình hoàn toàn khác để có thể mở rộng chức năng cho hệ thống.

Sealing

Sealing (sử dụng từ khóa sealed trong C#) là một cách hạn chế tính đa hình đối với class của bạn. Nếu bạn làm chủ hoàn toàn việc khai báo và thực thi, sealing sẽ giúp ích rất nhiều cho hiệu năng vì nó cho phép sử dụng lời gọi trực tiếp (direct call) cũng như chèn mã lệnh thực thi (inline).

Type và API rối rắm

Xu hướng chung khi pháp triển mã lệnh được quản lý (managed code) là có rất nhiều class cũng như khai báo được tạo ra nhằm phân nhỏ công việc mà chúng thực thi. Đây có thể là nguyên tắc thiết kế tốt nhưng không phải lúc nào cũng thích hợp. Hãy cân nhắc công việc thật cẩn thận và đảm bảo rằng các API được chia vừa đủ nhỏ (xem thêm bên dưới) để thực hiện tốt công việc. Đừng quên rằng mỗi lớp hay hàm đều có một liên kết tĩnh đến nó. Có thể thực hiện mọi thứ với ít class hay hàm hơn sẽ mang lại hiệu năng tốt hơn. Hãy đảm bảo rằng bạn không thêm mọi thứ vào class chỉ vì ý thích.

Phân mảnh API

Kích thước sai của API thường dẫn đến kích thước sai của các giao dịch tới cơ sở dữ liệu hay bộ nhớ lưu trữ. Hãy cân nhắc cẩn thận các vấn đề như đơn vị công việc (độ lớn của giao dịch như thế nào) và sự phân lập ngay cả khi bạn không làm việc trực tiếp với cơ sở dữ liệu. Việc nghĩ về các cấu trúc trong bộ nhớ như là các cấu trúc trong cơ sở dữ liệu thường mang lại hiệu quả tốt; chúng cần được truy cập đồng thời ngay cả khi thực tế chưa cần đến.

Concurrency (đồng thời)

Đừng sử dụng các mô hình đồng thời phức tạp nhiều hơn mức cần thiết. Đa số các trường hợp mô hình tối giản là tất cả những gì bạn cần. Các quy tắc chia sẻ phức tạp hay đồng bộ ở mức độ thấp thường mang lại vấn đề cho bạn hơn là giúp ích thực sự. Đặt các logic đồng bộ ở lớp nào làm việc với các “transaction”, không thêm vào ở các lớp cao hơn hay thấp hơn mỗi khi bạn có thể. Sử dụng các phương pháp đồng bộ phức tạp đòi hỏi kiến thức chuyên sâu về điểm mạnh cũng như điểm yếu trong mô hình bộ nhớ của bộ xử lý.

Ít DLL hơn

Coi như mọi chức năng là như nhau, bạn sẽ có hiệu năng tốt hơn với số ít DLL lớn thay vì nhiều DLL nhỏ. Đôi khi điểm này không thực sự chính xác, đặc biệt khi DLL khởi tạo quá mức các thành phần của nó. Trường hợp nhiều DLL mang lại hiệu quả là khi chia tách, bạn có cơ hội không phải tải chúng vào bộ nhớ khi chạy các chức năng thông thường. Hãy nhập các DLL lại nếu đó là việc làm có nghĩa.

Late Bound Semantics (truy xuất được xác định ở thời điểm thực thi)

Nếu bạn không cần Reflection thì đừng sử dụng chúng. Bạn không thể đạt được hiệu năng như “early-bound semantic” (truy xuất đến đối tượng được xác định ở thời điểm biên dịch) khi làm việc trên các kiểu thông qua Reflection. Nếu bạn sử dụng Reflection để tăng khả năng mở rộng, hãy cân nhắc tình huống liệu nó có đáng đánh đổi bằng hiệu năng bạn phải bỏ ra không.

Ít con trỏ hơn

Tôi thích nhìn mã lệnh có nhiều mảng các kiểu nguyên thủy hơn là một rừng các con trỏ. Các cấu trúc dữ liệu con trỏ phức tạp thường làm việc không tốt trên các bộ nhớ hiện tại. Nếu bạn phải trả cho tôi 1000 vnđ cho mỗi con trỏ, đến cuối năm bạn sẽ mất bao nhiêu tiền?

Bộ nhớ đệm và chính sách bộ nhớ đệm

Đảm bảo rằng bất kì bộ nhớ đệm nào bạn tạo ra đều có chính sách tốt, rõ ràng cho việc loại bỏ cũng như thời gian tồn tại của dữ liệu bên trong. Bộ nhớ đệm không phải để phình ra mãi mãi. Nếu không có chính sách phù hợp, bộ nhớ đệm sẽ trở thành memory leak (rò rỉ bộ nhớ). Sử dụng con trỏ yếu (WeakReference trong .NET) cho bộ nhớ đệm nhìn có vẻ đẹp nhưng thường thì bạn vẫn phải chịu hậu quả từ một chính sách không tốt.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s