Каков наилучший способ хранения графа объектов Entity Framework в памяти?

Question

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

Когда я впервые написал это, я извлек каждую сущность из базы данных, которая соответствовала сущности, с которой я сравнивал, у меня также было несколько включений, чтобы получить ссылочные сущности, которые мне также нужно было сравнить. Это было невероятно медленно, потому что каждое сравнение включало запрос к базе данных, а затем Entity Framework «исправлялся».

Сейчас я использую запрос, чтобы получить все сущности, которые мне нужны для моих сравнений, прежде чем я начну процесс. Это позволяет мне заранее оценить скорость, чтобы я мог значительно ускорить процесс. Однако первоначальный запрос по-прежнему занимает не менее минуты или двух.

Dictionary<long, SomeEntity> someEntities = new SomeEntitiesInclude().ApplyTo(context.SomeEntities)
                                                        .Where(se => se.SomeRelatedEntity.ID == relatedEntityID)
                                                        .Where(se => se.SCDCurrent == true)
                                                        .OrderBy<SomeEntity, long>(se => se.SomeRelatedEntity.ID)
                                                        .ToDictionary<SomeEntity, long>(se => se.SomeRelatedEntity.ID);

Фактический sql-запрос, полученный из этого, занимает всего пару секунд, поэтому я думаю, что большую часть времени тратится на исправление, чтобы контекст мог отслеживать изменения.

Объект SomeEntitiesInclude позволяет мне использовать строго типизированные операторы include и является подклассом класса IncludeStratergy, разработанного Алексом Джеймсом: http://blogs.msdn.com/alexj/archive/2009/07/25/tip-28-how-to-implement-include-strategies.aspx

У кого-нибудь есть советы, чтобы ускорить выполнение этого?

Извиняюсь за длинный вопрос.

Джеймс

Answer 1

Есть несколько вещей, которые могут замедлить это. Исправь это одно из них. Легко проверить, является ли проблема исправлением, проецируя на не-сущностный тип. Это полностью устраняет проблему с уравнением. Если это решит проблему, то, вероятно, это было исправлено, замедляя процесс, и мы можем задействовать решение оттуда.

С другой стороны, это может не решить проблему, потому что есть другие вещи, которые могут замедлить выполнение запроса. Первое, на что я бы обратил внимание - это компиляция запроса из выражения LINQ в SQL. Вы можете отделить этот шаг, используя тип CompiledQuery. Если создание CompiledQuery занимает много времени, но выполнение результирующего метода занимает очень мало времени, значит, вы обнаружили источник проблемы с производительностью.

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