Кэшировать или не кэшировать - GetCustomAttributes

В настоящее время у меня есть функция:

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;
}

Мне интересно, стоит ли кэшировать все атрибуты свойства в Словарь Attribute = _cache[MemberInfo][Type],

Для этого потребуется использовать GetCustomAttributes без какого-либо параметра типа, а затем перечислить результат. Стоит ли это?

Ответ 1

Если вы замените тело своего метода, вы получите лучшие чеки для своих баксов:

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)
    {
        // ...
    }
}

Каждый раз проверяет поиск словарей. Плюс это threadafe:)

Cheers, Флориан

PS: Зависит от того, как часто вы это называете. У меня были некоторые случаи, когда много сериализации с использованием рефлексии, действительно вызываемой для кэширования, как обычно, является motus operandi:

Запись
Тест
Debug
Тест снова
Профиль процессора
Профиль защиты
Оптимизация
Тест еще раз
Профиль процессора
Профиль MEM Это важно, так как ваша оптимизация связанного кода cpu, безусловно, перенесет нагрузку на память

Ответ 2

Единственный способ, которым вы можете точно знать, - это профилировать его. Мне жаль, если это звучит как клише. Но причина, почему высказывание является клише, часто объясняется тем, что это правда.

Кэширование атрибута на самом деле делает код более сложным и более подверженным ошибкам. Поэтому вы можете принять это во внимание - ваше время разработки - прежде чем вы решите.

Так же, как и оптимизация, не делайте этого, если вам не нужно.

Из моего опыта (я говорю о приложении для AutoCAD, таком как Windows Application, с большим количеством операций с графическим интерфейсом с кликом и большим количеством хрустов), чтение пользовательского атрибута никогда - даже один раз - производительность узкое место.

Ответ 3

Ваш вопрос - это преждевременная оптимизация.

Вы не знаете внутренней работы классов отражения и поэтому делаете предположения о последствиях производительности вызова GetCustomAttributes несколько раз. Сам метод может уже кэшировать свой результат уже, что означает, что ваш код действительно добавит накладные расходы без улучшения производительности.

Сохраняйте свои мозговые циклы для размышлений о вещах, которые вы уже знаете, являются проблемами!

Ответ 4

У вас действительно проблема с производительностью? Если нет, тогда не делайте этого, пока это вам не понадобится.

Это может помочь в зависимости от того, как часто вы вызываете метод с теми же параметрами. Если вы вызываете его только один раз за MemberInfo, Type, то это не принесет пользы. Даже если вы делаете кеш-память, вы торгуете скоростью для потребления памяти. Это может быть хорошо для вашего приложения.

Ответ 5

Старый вопрос, но GetCustomAttributes - дорогостоящий/тяжеловесный

Использование кеша, если оно вызывает проблемы с производительностью, может быть хорошей идеей

В статье, которую я связал: (Dodge Common Performance Pitfalls для создания быстрых приложений) был снят, но здесь ссылка на архивированную версию:

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

Ответ 6

У меня был сценарий, когда GetCustomAttributes оказался узким местом производительности. В моем случае его вызывали сотни тысяч раз в наборе данных со многими строками, и это затрудняло выделение проблемы. Кэширование атрибутов решило проблему.

Предварительное тестирование привело к едва заметной производительности, достигающей около 5000 вызовов на современной машине. (И это стало значительно более заметным по мере увеличения размера набора данных.)

Я вообще согласен с другими ответами о преждевременной оптимизации, однако, по шкале инструкции процессора для вызова БД, я бы предположил, что GetCustomAttributes больше склоняется к последнему.