(Tại sao) Phản ánh quá đắt trong .Net?

Question

thể trùng lặp:
What is the “cost” of reflection?

Có ai có một lời giải thích tốt của thần chú được chấp nhận chung rằng reflection == bad performance? Ví dụ, tốn bao nhiêu để lặp qua bộ sưu tập thuộc tính của một loại và trích xuất tất cả các giá trị thuộc tính từ một thể hiện kiểu này so với chỉ truy cập trực tiếp tất cả các thuộc tính? Một mức độ lớn? Hai? Nó phụ thuộc vào điều gì? Có thể dự đoán được không? Điều gì đang xảy ra dưới mui xe?

EDIT: Cảm ơn bạn đã trả lời cho đến thời điểm này. Tôi đã xem xét một số liên kết mà bạn cung cấp và có vẻ như có một khoảng cách lớn về ước tính có liên quan đến Phản ánh trên Thuộc tính so với truy cập trực tiếp: từ 2,5 lần chậm hơn đến 200 lần.

Điều này có vẻ không hợp lý đối với tôi. Một số bạn đã đề cập đến cải tiến hiệu suất trong các phiên bản sau của .Net vì vậy hãy thu hẹp câu hỏi của tôi thành .Net 4.0. Có ai có bất kỳ điểm chuẩn cho điều đó?

Answer 1

Ai quan tâm những gì người khác nghĩ? Nếu bạn đã thực hiện một cuộc điều tra có giáo dục về các lựa chọn của bạn (bao gồm các cách tiếp cận khác không yêu cầu kỹ thuật bạn đang điều tra), và nhận thấy đó là lựa chọn đúng, hãy sử dụng nó.

http://www.parashift.com/c++-faq-lite/big-picture.html#faq-6.16

Đối với "những gì đang xảy ra dưới mui xe", bạn dường như có một phần của hình ảnh. Cũng có một thực tế là không có liên kết nào được mã hóa cứng, tất cả phải được tra cứu trong thời gian chạy. Điều này có nghĩa là không có lớp lót có thể xảy ra, không có lỗi trình biên dịch nào được tạo nếu bạn nhập sai tên thành viên và tất cả thành viên phải được tra cứu bằng chuỗi, với bất kỳ chuỗi liên kết nào so sánh số lần truy cập hoàn thiện (có thể hoặc không tồn tại, tùy thuộc vào nội dung giống như chuỗi ký tự, vv).

Edit:

Vâng, tôi đoán phần cuối cùng này của câu trả lời của tôi là không nhất thiết phải chính xác. Nó phụ thuộc phần lớn vào cách bạn sử dụng phản xạ. Hồ sơ! Và nếu bạn nghĩ ra giải pháp thay thế, hồ sơ cũng vậy. :)

Answer 2

Có một số câu hỏi về SO trả lời câu hỏi này theo nhiều cách khác nhau.

Dưới đây là một trong những tốt IMO: What is the "cost" of .NET reflection?

Một trong những articles the answerer links đưa ra một số thông tin thú vị về chức năng nhất định phản ánh được nhiều hơn tốn kém hơn những người khác. Ví dụ, làm một typeof không phải là quá xấu, nhưng gọi phương pháp là tốn kém hơn.

Answer 3

Câu trả lời hay nhất là câu thần chú được chấp nhận chung không đơn giản như nó có vẻ. reflection == bad performance phần lớn có nguồn gốc với .NET 1.0 và 1.1 và không xác nhận các cải tiến hiệu suất trong các phiên bản sau.

Để đạt được mục tiêu, tôi đã thử nghiệm các giải pháp dựa trên phản chiếu so với các giải pháp dựa trên không phản chiếu trong một số trường hợp - và người chiến thắng không phải lúc nào cũng là một hoặc khác.Phản ánh là nó là gì và nó hoạt động như thế nào, nó không nhanh hơn hoặc chậm hơn và (như về cơ bản tất cả các cách tiếp cận lập trình) không thể được coi là một viên đạn bạc hay là thứ gì đó luôn tránh được.

Answer 4

Có rất nhiều quan niệm sai lầm về sự phản ánh liên quan.

This guy đã cho thấy rằng một phản xạ mất khoảng 3 lần dài hơn so với gán trực tiếp. Trong thực tế, tính năng này được sử dụng đúng cách sẽ không có tác động đáng kể đến hiệu suất. Không có gì sai khi sử dụng phản xạ trong ngữ cảnh chính xác.

Answer 5

Có một số điều bạn không thể làm với tĩnh. Sử dụng sự phản chiếu khi bạn cần. Bạn có thể đã sử dụng nó nhiều hơn bạn nhận ra.

Tôi đã thực hiện nhiều phép thử và phép đo hiệu suất cho các hoạt động phản chiếu và tĩnh. Phản ánh có nhiều việc phải làm và luôn chậm hơn. Nhưng nó ổn. "Chậm" không có nghĩa là "chậm", nó chỉ có nghĩa là "không nhanh". Đó là cách nó nên được xem xét. Phản ánh vẫn có thể nhanh, không nhanh bằng thao tác tĩnh. Nó không nên tự động bị tránh xa vì điều này.

Tôi đã làm việc cho các nhà phát triển chính, những người tuyệt đối cấm bất kỳ mã phản chiếu nào trong dự án web vì nó sẽ chậm. Nhưng nó không bao giờ dường như xảy ra với anh ta rằng chúng tôi đã sử dụng NHibernate, ASP.NET và ASP.NET MVC dữ liệu ràng buộc, tất cả đều làm việc gần như độc quyền với các ràng buộc dữ liệu phản chiếu.

Sự ác cảm của người đó để phản ánh là vô lý và vô căn cứ. Tôi nghĩ đây là trường hợp với rất nhiều người bạn nói về nó.