(왜) 리플렉션이 .NET에서 너무 비쌉니까?

Question

가능한 중복 :
What is the “cost” of reflection?

사람이 reflection == bad performance이 일반적으로 수용되는 만트라의 좋은 설명이 있습니까?

예를 들어 유형의 속성 컬렉션을 반복하고 모든 속성에 직접 액세스하는 것보다이 유형의 인스턴스에서 모든 속성 값을 추출하는 것이 얼마나 비쌉니까? 규모의 한 수준? 두? 무엇에 의존 하는가? 전혀 예측할 수 있습니까? 후드 아래에서 무슨 일이 일어나고 있습니까?

편집 : 답변 주셔서 감사합니다. 필자가 제공 한 몇 가지 링크를 살펴 봤는데 직접 액세스와 비교하여 속성에 대한 리플렉션과 관련하여 추정치가 상당히 차이가 나는 것으로 보입니다. 2.5 배 느리게 200 배 느리게.

이것은 나에게별로 합리적이지 않습니다. 여러분 중 일부는 .Net의 이후 버전에서 성능 향상에 대해 언급 했으므로 .Net 4.0에 대한 제 질문의 범위를 좁히십시오. 누구든지 벤치 마크가 있습니까?

Answer 1

누가 다른 사람들의 생각을 신경 쓰나요? 조사한 기술을 필요로하지 않는 다른 접근법을 포함하여 귀하의 선택 사항에 대해 숙련 된 조사를 한 결과 올바른 선택이라고 판단되면 사용하십시오. 에 관해서는

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

"후드 아래에 무슨 일이,"당신은 사진의 일부를 갖고있는 것 같다. 또한 링크가 하드 코드되지 않으며 런타임에 모두 찾아야합니다. 이것은 in-lining이 불가능하다는 것을 의미합니다. 멤버 이름을 잘못 입력하면 컴파일러 오류가 발생하지 않으며 문자열을 사용하여 모든 멤버를 조회해야합니다. 관련 문자열은 perf 히트를 비교합니다 (물건에 따라 존재할 수도 있고 존재하지 않을 수도 있음). 인턴 같은 문자열 등).

편집 :

글쎄, 나는 내 대답의 마지막 부분은 반드시 정확하지 않은 것 같아요. 반사 작용을 사용하는 방법에 따라 크게 좌우됩니다. 윤곽! 대체 솔루션을 생각해 내면 프로필도 작성하십시오. :)

Answer 2

이렇게 대답하는 방법에는 여러 가지가 있습니다. articles the answerer links의 What is the "cost" of .NET reflection?

하나는 다른 사람보다 더 많은 비용이 많이 드는 것을 반성의 특정 기능에 대한 몇 가지 흥미로운 정보를 제공합니다

여기 IMO 좋은 하나입니다. 예를 들어, typeof를 수행하는 것은 그렇게 나쁘지는 않지만 메소드 호출은 비용이 많이 든다.

Answer 3

가장 좋은 대답은 일반적으로 받아 들여지는 만트라가 그 것처럼 단순하지 않다는 것입니다. reflection == bad performance은 주로 .NET 1.0 및 1.1에서 시작되었으며 이후 버전의 성능 향상을 인정하지 않습니다.

객관성을 높이기 위해 반사 기반 솔루션과 비 반사 기반 솔루션을 여러 가지 경우에 테스트 해 보았습니다. 수상자가 항상 하나가되는 것은 아닙니다.리플렉션은 그것이 무엇이며 작동하는 방식으로 작동하며 일관성있게 더 빠르거나 느리지 않으며 기본적으로 모든 프로그래밍 방식과 마찬가지로 은색 총으로 또는 항상 피할 수있는 것으로 취급 될 수 없습니다.

Answer 4

반사와 관련하여 많은 오해가 있습니다.

은 반사가 직접 할당보다 약 3 배 더 오래 걸리는 것으로 나타났습니다. 실제로이 기능을 올바르게 사용하면 성능에 큰 영향을 미치지 않습니다. 올바른 상황에서 반사를 사용하는 데는 아무 문제가 없습니다.

Answer 5

정적으로 할 수없는 몇 가지 사항이 있습니다. 필요할 때 반성을 사용하십시오. 이미 사용하고있는 것보다 더 많이 사용했을 것입니다.

리플렉션 대 정적 작업에 대한 많은 성능 테스트와 측정을 수행했습니다. 반사에는 할 일이 많으며 항상 느립니다. 하지만 그건 괜찮아. "느리게"는 "느린"을 의미하지 않으며 "빠르지 않다"를 의미합니다. 그것이 어떻게 고려되어야하는지입니다. 반사는 여전히 정적 일만큼 빠르지 않고 빠르다. 이 때문에 자동으로 기권해서는 안됩니다.

나는 느릴 수 있기 때문에 웹 프로젝트에서 반사 코드를 절대적으로 금지하는 수석 개발자를 위해 일했습니다. 그러나 우리가 NHibernate, ASP.NET 및 ASP.NET MVC 데이터 바인딩을 사용하고 있다는 사실은 그에게 결코 보이지 않았습니다. 이들 모두는 거의 독점적 인 데이터 바인딩으로 만 작동합니다.

반사에 대한 그 사람의 혐오감은 불합리하고 근거가 없습니다. 나는 이것이 당신이 그것에 대해 많은 사람들과 이야기하는 경우라고 생각합니다.