W jaki sposób działa funkcja API Reflections, na przykład GetType() i GetTypes()?

Question

Używam interfejsów API do odczytywania, takich jak GetType() i GetTypes() w .NET/C#.

• Pod względem wydajności, jak dobre lub złe są te interfejsy API? Mam na myśli, czy te interfejsy API zajmują dużo czasu, który może spowodować obniżenie wydajności lub czy te interfejsy API są dobrze zaprojektowane, aby ignorować problemy z wydajnością?
• Czy zwykle ludzie buforują wyniki, gdy używają interfejsów API do odczytywania?

Answer 1

Nie wiemy, co znaczy "dobry" i "zły".

Nie wiemy, czy używasz ich w krytycznym kodzie wydajności, który może być wąskim gardłem dla twojej aplikacji.

Tylko Ty znasz dokładnie ścieżki, które Twój kod będzie używał podczas używania Object.GetType i Assembly.GetTypes.

W związku z tym, tylko Ty możesz profilować dokładnie, jak istotne będzie wykorzystanie tych metod w działaniu aplikacji i jak korzystne będzie zwiększenie wydajności poprzez buforowanie.

mogę ci to powiedzieć: Nigdy nie miałem Type.GetType i Assembly.GetTypes być wąskim gardłem w mojej aplikacji, a ja nie buforują wyniki (Mam jednak potrzebne, aby buforować MemberInfo.GetCustomAttributes ale doszedłem tylko do tego wniosku po profiler powiedział mi, że było to wąskie gardło w mojej aplikacji i że buforowanie znacznie poprawiłoby wydajność).

Odpowiadając na swojej EDIT:

To znaczy, są te API zajmują dużo czasu, które mogą powodować pewne pogorszenie wydajności lub są te API dobrze zaprojektowany, aby ignorować problemy z wydajnością?

Jakie masz alternatywy? Jeśli potrzebujesz odniesienia do Type dla danego obiektu lub potrzebujesz wszystkich typów w danym zestawie, zapewniam, że najlepszym wyborem są Object.GetType i Assembly.GetTypes. Pytanie brzmi: w jaki sposób je wykorzystujesz? Ponownie, nie wiemy, a zatem nie mogę powiedzieć, co robić. Musisz profilować swoje rzeczywiste wykorzystanie tych funkcji i dowiedzieć się, czy powodują one wąskie gardło w Twojej aplikacji, czy nie.

Answer 2

Obydwie są wyjątkowo wydajne i mają wyjątkowo słabą wydajność. Wszystko zależy od twojej perspektywy i porównania.

Serwery interfejsu API Reflection to cel i większość zastosowań tych interfejsów API, które nie utworzą wąskiego gardła. Użyj ich.

Jeśli po intensywnym korzystaniu z nich powstaje wąskie gardło widoczne w profilowaniu, istnieją opcje poprawy wydajności. Możesz wdrożyć buforowanie po swojej własnej stronie i możesz użyć generowania kodu czasu w czasie wykonywania lub kompilacji.

Większość ORM używa refleksji do wypełniania obiektów obiektu, a ponieważ jest to czynność wykonywana wielokrotnie w bardzo dużej objętości, może stać się wąskim gardłem wydajności. Niektóre nowsze mikro-ormia używają klas wygenerowanych przez środowisko wykonawcze, które mogą budować jednostki bez refleksji (używając Reflection.Emit). W naszym projekcie używamy klas generowanych podczas kompilacji, aby tworzyć budowniczych dla każdej jednostki. Wygenerowany czas kompilacji jest łatwiejszy i ma najlepszą wydajność, jeśli działa w twojej sytuacji.