Данные отражения кэширования

Ответ 1

ConcurrentDictionary<WeakReference, CachedData> неверно в этом случае. Предположим, мы пытаемся кэшировать информацию для типа T, поэтому WeakReference.Target==typeof(T). CachedData скорее всего будет содержать ссылку для typeof(T). Поскольку ConcurrentDictionary<TKey, TValue> хранит элементы во внутренней коллекции Node<TKey, TValue>, у вас будет цепочка сильных ссылок: ConcurrentDictionary instance → Node instance → Value property (CachedData instance) → typeof(T). В общем случае невозможно избежать утечки памяти с помощью WeakReference в случае, когда значения могут иметь ссылки на их ключи.

Необходимо было добавить поддержку эфемеронов, чтобы сделать такой сценарий возможным без утечек памяти. К счастью,.NET 4.0 поддерживает их, и у нас есть класс ConditionalWeakTable<TKey, TValue>. Кажется, причины, чтобы представить его, близки к вашей задаче.

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

Ответ 2

Вы должны проверить более быстрый библиотека

Вы можете использовать нормальное отражение для динамического создания нового кода & затем сгенерируйте/скомпилируйте его и затем кэшируйте скомпилированную версию. Я думаю, что идея коллекционной сборки является многообещающей, чтобы избежать утечки памяти без необходимости загружать/выгружать из отдельного домена приложения. Однако утечка памяти должна быть незначительной, если вы не компилируете сотни методов.

Вот блог о динамической компиляции кода во время выполнения: http://introspectingcode.blogspot.com/2011/06/dynamically-compile-code-at-runtime.html

Ниже приведен аналогичный подход к параллельному словарю, который я использовал в прошлом для хранения объектов MethodInfo/PropertyInfo & Казалось, что это было быстрее, но я думаю, что это было в старой версии Silverlight. Я считаю, что .Net имеет свой собственный внутренний кэш отражения, который делает его ненужным.

using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;
using System.Reflection;
using System.Collections.Concurrent;

namespace NetSteps.Common.Reflection
{
    public static class Reflection
    {
        private static ConcurrentDictionary<Type, Dictionary<string, PropertyInfo>> reflectionPropertyCache = new ConcurrentDictionary<Type, Dictionary<string, PropertyInfo>>();
        public static List<PropertyInfo> FindClassProperties(Type objectType)
        {
            if (reflectionPropertyCache.ContainsKey(objectType))
                return reflectionPropertyCache[objectType].Values.ToList();

            var result = objectType.GetProperties().ToDictionary(p => p.Name, p => p);

            reflectionPropertyCache.TryAdd(objectType, result);

            return result.Values.ToList();
        }

    }
}

Ответ 3

Я мог бы заявить очевидное здесь, но:

Не кэшировать поставщиков обычно сериализуют данные в источник?

Таким образом, процесс десериализации будет более дорогостоящим, чем просто отражением нового экземпляра?

Или я что-то пропустил?

И вот весь аргумент в отношении бокса и времени распаковки... не уверен, действительно ли это имеет значение.

Edit:

Как насчет этого (надеюсь, это объясняет проблему немного лучше)...

Dictionary<string, Type> typecache = new Dictionary<string, Type>();

// finding a type from say a string that points at a type in an assembly not referrenced
// very costly but we can cache that
Type myType = GetSomeTypeWithReflection();
typecache.Add("myType", myType);

// creating an instance you can use very costly
MyThingy thingy = Activator.CreateInstance(typecache["myType"]);

Вы хотите кэшировать "thingy"?