LINQ Expressions и Рефлексия

159

21 апреля 2019, 22:10

Наткнулся на очень интересный код:

using System.Linq.Expressions;
class FieldAccessor
{
    private static readonly ParameterExpression fieldParameter = Expression.Parameter(typeof(object));
    private static readonly ParameterExpression ownerParameter = Expression.Parameter(typeof(object));
    public FieldAccessor(Type type, string fieldName)
    {
        var field = type.GetField(fieldName,
            BindingFlags.Instance | BindingFlags.Public | BindingFlags.NonPublic);
        if (field == null) throw new ArgumentException();
        var fieldExpression = Expression.Field(
            Expression.Convert(ownerParameter, type), field);
        Get = Expression.Lambda<Func<object, object>>(
            Expression.Convert(fieldExpression, typeof(object)),
            ownerParameter).Compile();
        Set = Expression.Lambda<Action<object, object>>(
            Expression.Assign(fieldExpression,
                Expression.Convert(fieldParameter, field.FieldType)), 
            ownerParameter, fieldParameter).Compile();
    }
    public Func<object, object> Get { get; }
    public Action<object, object> Set { get; }
}

Автор утверждает, что он производительный стандартной рефлекссии и даже ответ отмечен, как принятый.

Однако, не понимаю, чем он лучше стандартного кеширования поля. Или это плацебо?

Answer 1

Здесь кэшируется не само поле, а метод доступа к нему. Подразумевается, что для каждого поля класса, которое требуется динамически устанавливать или читать, создаётся свой экземпляр класса FieldAccessor. После этого созданный объект используется многократно. Если то же самое делать по старинке, выглядеть это будет так:

FieldInfo pi = type.GetField(fieldName, /* те же самые флаги */);
return pi.GetValue(object);

Этот вызов будет медленнее, чем динамически сгенерированный аксессор специально для указанного поля, т.к. через лямбда-выражение мы генерируем код, содержащий только обращение к полю так, как будто бы мы написали просто return fieldName. Правда, он будет упакован в делегат, что всё равно даст некоторый overhead по сравнению с обычным полем. В принципе, в .NET 1 или 2, где ещё не было интерпретируемых запросов, такое тоже можно было сделать посредством генерации MSIL на Reflection.Emit, но это гораздо сложнее. Возможность описания лямбда-выражения как структуры данных с последующей компиляцией делает то же самое гораздо проще.

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

ПОСЛЕДНИЕ ВОПРОСЫ

Все вопросы

ТОП-10

Все популярные вопросы

LINQ Expressions и Рефлексия

Ошибка NullReferenceException: Object reference not set to an instance of an object. Не понимаю суть проблемы [дубликат]

Не удаляется часть строки (string) в C#

Как добавить DataGrid в ячейку?

C# Контроль времени выполнения Task и его отмена