LINQ Expressions и Рефлексия
Наткнулся на очень интересный код:
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; }
}
Автор утверждает, что он производительный стандартной рефлекссии и даже ответ отмечен, как принятый.
Однако, не понимаю, чем он лучше стандартного кеширования поля. Или это плацебо?
Здесь кэшируется не само поле, а метод доступа к нему. Подразумевается, что для каждого поля класса, которое требуется динамически устанавливать или читать, создаётся свой экземпляр класса FieldAccessor. После этого созданный объект используется многократно. Если то же самое делать по старинке, выглядеть это будет так:
FieldInfo pi = type.GetField(fieldName, /* те же самые флаги */);
return pi.GetValue(object);
Этот вызов будет медленнее, чем динамически сгенерированный аксессор специально для указанного поля, т.к. через лямбда-выражение мы генерируем код, содержащий только обращение к полю так, как будто бы мы написали просто return fieldName. Правда, он будет упакован в делегат, что всё равно даст некоторый overhead по сравнению с обычным полем. В принципе, в .NET 1 или 2, где ещё не было интерпретируемых запросов, такое тоже можно было сделать посредством генерации MSIL на Reflection.Emit, но это гораздо сложнее. Возможность описания лямбда-выражения как структуры данных с последующей компиляцией делает то же самое гораздо проще.
Надо помнить, что получение поля по имени и тем более компиляция лямбда-выражения в MSIL - это операции не моментальные, поэтому выигрыш в производительности от использования такого класса мы получим только в том случае, когда мы создали один объект для каждого поля, а потом многократно его используем.
-
14:06
-
21:33
Виртуальный выделенный сервер (VDS) становится отличным выбором
-
22:26
-
22:40
-
08:34
-
15:01
-
17:01
-
11:24
-
10:16
- Почему SERVER_ADDR имеет не тот IP 47696 visits
- Как заменить $_SERVER[REMOTE_ADDR] на IP клиента в PHP за двумя Nginx? 30544 visits
- Хочу вывести несколько строк из массива в один div, выводит только много undefined; подскажите, что делать? 23722 visits
- Как через css изменить цвет png изображения? 10373 visits
- Blob video url download 9980 visits
- Php curl запрос через прокси с авторизацией 9239 visits
- Работа с captcha vk api 8116 visits
![Ошибка NullReferenceException: Object reference not set to an instance of an object. Не понимаю суть проблемы [дубликат]](https://hostciti.net/images/nophoto.png "Ошибка NullReferenceException: Object reference not set to an instance of an object. Не понимаю суть проблемы [дубликат]")
© "hostciti.net" 23.1.2025 | 19:03