Кэшироваться или не кэшироваться - GetCustomAttributes
Протестированный с a, b, p от 0 до 10 000:
a != 1 && a != (b-p-1) && a <= (b-p);
я думаю, что это может быть упрощено еще больше.
4 ответа
Вы получите лучшую отдачу от своих денег, если вы замените тело вашего метода следующим образом:
return Attribute.GetCustomAttribute(Member, AttributeType,false); // only look in the current member and don't go up the inheritance tree.
Если вам действительно нужно кэшировать по типу:
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)
{
// ...
}
}
Лучше поиск по словарю каждый раз. Плюс это потокобезопасный :)
Ура, Флориан
PS: Зависит от того, как часто вы это называете. У меня были случаи, когда выполнение большого количества сериализации с использованием отражения действительно требовало кеширования, как обычно, принцип работы такой:
- Запись
- Тест
- Отладка
- Тест снова
- Профиль процессора
- ] Профиль памяти
- Оптимизация
- Протестируйте еще раз
- Профиль процессора
- Профиль MEM Этот профиль важен, поскольку ваша оптимизация кода, связанного с процессором, определенно перекладывает нагрузку на память
Единственный способ узнать наверняка - это профилировать его. Прошу прощения, если это звучит как клише. Но причина, по которой поговорка является клише, часто заключается в том, что она правда.
Кеширование атрибута на самом деле делает код более сложным и подверженным ошибкам. Так что вы можете принять во внимание это - время разработки - прежде чем принимать решение.
Так же, как и с оптимизацией, не делайте этого, если в этом нет необходимости.
По моему опыту (я говорю о приложении Windows, подобном AutoCAD, с большим количеством операций графического интерфейса для редактирования щелчком и большим количеством вычислений), чтение настраиваемого атрибута никогда - даже однажды - не является узким местом производительности.
Ваш вопрос касается преждевременной оптимизации.
Вы не знаете, как работают классы отражения, и поэтому делаете предположения о последствиях для производительности вызова GetCustomAttributes несколько раз. Сам метод может уже кэшировать свой вывод, а это означает, что ваш код фактически добавит накладные расходы без повышения производительности.
Сохраните циклы своего мозга, чтобы думать о вещах, которые, как вы уже знаете, являются проблемами!
У вас действительно проблемы с производительностью? Если нет, не делайте этого, пока он вам не понадобится.
Это может помочь в зависимости от того, как часто вы вызываете метод с одинаковыми параметрами. Если вы вызовете его только один раз для комбинации MemberInfo , Тип , то это не принесет никакой пользы. Даже если вы его кешируете, вы жертвуете скоростью на потребление памяти. Это может подойти для вашего приложения.