Nhái Cốm Blog

I love you just the way you are


Leave a comment

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

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 comment

Xuyên tạc thơ

Đây là một đoạn bài “Hạt gạo làng ta” mà Nhái con đọc.

Hạt gạo làng ta
Có công các bạn
Sáng nào bắt sâu
Vục
mẹ miệng gầu =))

Còn đây là nguyên văn đoạn thơ

Hạt gạo làng ta
Có công các bạn
Sớm nào chống hạn
Vục mẻ miệng gầu
Trưa nào bắt sâu
Lúa cao rát mặt
Chiều nào gánh phân
Quang trành quết đất.


Leave a comment

Xin lỗi Nhái con

Suốt cả buổi tối tâm trạng thực sự là không thoải mái, lúc nào cũng chỉ muốn quát lên cãi nhau với một ai đó. Mấy lần định gắt lên với con, mới nói vài từ đành cố kiềm chế không nói tiếp. Đến giờ đi ngủ, dặn con đánh răng cẩn thận không là ướt áo nhưng kết quả là cái áo vẫn ướt. Như giọt nước làm tràn ly, mình mắng con mà thâm tâm cũng không hiểu là tại sao lại làm thế.

Nhái con khóc ! Được một lúc thì nôn ra một ít đờm (may mà không nôn ra thức ăn). Lúc đi làm về nghe tin hôm nay có không khí lạnh cường độ yếu. Không khéo con lại ốm.

Con lên giường đi ngủ. Mình vào ôm con hỏi:

– Lúc nãy đánh răng Nhái nghịch nước nên áo bị ướt à?

– Không, tại con nhổ nước mạnh quá nên áo bị ướt.

– Thế bố mắng sai Nhái con à? Cho bố xin lỗi nhé 😦

– Vâng! À bố Ngọc ơi, con biết tàu ngầm tiếng Anh là gì rồi đấy..

Là mình ghen?

Giờ chỗ gần đỉnh đầu lại nhói đau. Mấy hôm nữa không hết chắc phải đi khám.

Mong mọi chuyện chỉ do mình bị đau đầu.