Aby buforować lub nie buforować - GetCustomAttributes

Question

Obecnie mam funkcję:

public static Attribute GetAttribute(MemberInfo Member, Type AttributeType) 
{ 
    Object[] Attributes = Member.GetCustomAttributes(AttributeType, true); 

    if (Attributes.Length > 0) 
     return (Attribute)Attributes[0]; 
    else 
     return null; 
} 

Zastanawiam się, czy warto byłoby buforowanie wszystkie atrybuty na nieruchomości w słowniku Attribute = _cache[MemberInfo][Type],

ten wymagałoby użycia GetCustomAttributes bez żadnego parametru typu, a następnie wyliczenia z wyniku. Czy warto?

Answer 1

Dostaniesz lepsze huki dla dolców jeśli zastąpić ciało metodę z tym:

return Attribute.GetCustomAttribute(Member, AttributeType,false); // only look in the current member and don't go up the inheritance tree. 

Jeśli naprawdę trzeba buforować na typu zasadach:

public static class MyCacheFor<T> 
{ 
    static MyCacheFor() 
    { 
     // grab the data 
     Value = ExtractExpensiveData(typeof(T)); 
    } 

    public static readonly MyExpensiveToExtractData Value; 

    private static MyExpensiveToExtractData ExtractExpensiveData(Type type) 
    { 
     // ... 
    } 
} 

Beats wyszukiwanie słownika za każdym razem. Plus to threadsafe :)

Cheers, Florian

PS: Zależy jak często nazywają to.Miałem kilka przypadków, w których robi wiele serializacji przy użyciu odbicia naprawdę nazwie do buforowania, jak zwykle, operandi motus to:

1. Zapis
2. test
3. Debug
4. test ponownie
5. CPU profil
6. Mem profilu
7. Optymalizacja
8. test jeszcze raz
9. CPU profilu
10. MEM Profil Ten jest ważne, jak optymalizacji procesora związany kod pewnością przesunięcia ciężaru do pamięci

Answer 2

Jedynym sposobem na pewno na pewno jest profilowanie. Przepraszam, jeśli to brzmi jak banał. Ale powód, dla którego powiedzenie jest banałem, często jest taki, że jest prawdziwy.

Buforowanie tego atrybutu powoduje, że kod jest bardziej złożony i bardziej podatny na błędy. Więc możesz wziąć to pod uwagę - czas twojego rozwoju - zanim podejmiesz decyzję.

Tak jak optymalizacja, nie rób tego, chyba że musisz.

Z mojego doświadczenia (mówię o AutoCAD-like aplikacji Windows, z dużą ilością operacji GUI kliknij, edytować i liczba ciężkich pożerające), odczyt z atrybutu niestandardowego nie jest - nawet once-- wąskim gardłem wydajności .

Answer 3

Czy masz problem z wydajnością? Jeśli nie, nie rób tego, dopóki go nie potrzebujesz.

Może to pomóc w zależności od tego, jak często wywoływana jest metoda z tymi samymi parametrami. Jeśli wywołasz tylko jeden raz na kombinację MemberInfo, Type, to nie przyniesie to żadnego pożytku. Nawet jeśli robisz pamięć podręczną, masz tendencję do zwiększania zużycia pamięci. To może być dobre dla twojej aplikacji.

Answer 4

Twoje pytanie dotyczy przypadku przedwczesnej optymalizacji.

Nie znasz wewnętrznego działania klas refleksji, a zatem przyjmujesz założenia dotyczące implikacji związanych z wydajnością wielokrotnego wywoływania GetCustomAttributes. Sama metoda może dobrze buforować już swoje wyniki, co oznacza, że ​​Twój kod rzeczywiście zwiększy obciążenie bez poprawy wydajności.

Oszczędzaj cykle mózgowe, myśląc o rzeczach, o których wiesz, że są problemami!

Answer 5

miałem tylko scenariusz, w którym GetCustomAttributes okazał się wąskim gardłem wydajności . W moim przypadku był wywoływany setki tysięcy razy w zbiorze danych z wieloma wierszami, co sprawiało, że problem był łatwy do wyizolowania. Buforowanie atrybutów rozwiązało problem.

Wstępne testy doprowadziły do ​​ledwo zauważalnego uderzenia wydajności w około 5000 połączeń na współczesnym komputerze. (I stało się drastycznie bardziej zauważalne, gdy rozmiar zbioru danych wzrósł).

Ogólnie zgadzam się z innymi odpowiedziami na temat przedwczesnej optymalizacji, jednak w skali instrukcji CPU do wywołania DB, sugeruję, że GetCustomAttributes pochyliłoby się bardziej w kierunku tego ostatniego.

Answer 6

Stare pytanie, ale GetCustomAttributes jest kosztowne/heavyweight

Korzystanie z pamięci podręcznej, jeśli to jest przyczyną problemów z wydajnością może być dobrym pomysłem

Artykuł I powiązany: (Dodge Common Wydajność Pułapki Craft Speedy Applications) został zdjęty, ale tutaj link do zarchiwizowanej wersji:

https://web.archive.org/web/20150118044646/http://msdn.microsoft.com:80/en-us/magazine/cc163759.aspx