.NET Linq to SQL Проблема производительности с унаследованными дискриминаторами

Question

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

Я выделил проблему, и, похоже, это какая-то проблема с самим кодом, сгенерированным LINQ to SQL..

Я создал пример программы, используя Northwind для уточнения проблемы.Возвращает первую строку Customer в обоих сценариях.Запрос к базе данных тривиален и выполняется <1 мс. </p>

. В «маленьком» сценарии он имеет 4 типа, с одним базовым клиентом и тремя производными типами, использующими наследование LINQ.

Большой«В этом сценарии более 60 типов с одним базовым клиентом и более 60 производных типов, использующих наследование LINQ с дискриминатором столбца INT.

Производительность LARGE datacontext ужасна по сравнению с первым (более 2 секунд),даже если это тот же запрос и возвращены те же данные.

Вот вывод.

Performance Comparison of LINQ to SQL
Run each 3 times in a row for cache
With 4 Inherited Tables
00:00:00.2340004 of Small Test for First Customer:A Bike Store
00:00:00 of Small Test for First Customer:A Bike Store
00:00:00 of Small Test for First Customer:A Bike Store
With >60 Inherited Tables
00:00:01.7004030 of Large TestFirst Customer:A Bike Store
00:00:00.0156000 of Large TestFirst Customer:A Bike Store
00:00:00.0156001 of Large TestFirst Customer:A Bike Store
With 4 Inherited Tables
00:00:00 of Small Test for First Customer:A Bike Store
00:00:00 of Small Test for First Customer:A Bike Store
00:00:00 of Small Test for First Customer:A Bike Store
With >60 Inherited Tables
00:00:00.0156000 of Large TestFirst Customer:A Bike Store
00:00:00.0156000 of Large TestFirst Customer:A Bike Store
00:00:00.0156001 of Large TestFirst Customer:A Bike Store
Press Any Key

Обратите внимание, что при первом запуске набора данных LARGE это занимает 1,7 секунды против .23секунд (в 7 раз медленнее)

Даже второй набор прогонов медленнее, но производительность приемлема.

Вот полное приложение для загрузки http://cid -02bee16e84f5c99f.office.live.com/self.aspx/Public/TestDalLinqPerformance.zip

Из нашей отладки, это как-то связано с этим сгенерированным кодом:

[global::System.Data.Linq.Mapping.InheritanceMappingAttribute(Code="2", Type=typeof(Customer2))]
    [global::System.Data.Linq.Mapping.InheritanceMappingAttribute(Code="67", Type=typeof(Customer67))]
    [global::System.Data.Linq.Mapping.InheritanceMappingAttribute(Code="65", Type=typeof(Customer65))]
    [global::System.Data.Linq.Mapping.InheritanceMappingAttribute(Code="615", Type=typeof(Customer615))]
    [global::System.Data.Linq.Mapping.InheritanceMappingAttribute(Code="513", Type=typeof(Customer613))]
    public partial class Customer : INotifyPropertyChanging, INotifyPropertyChanged

При генерации с плюсом 40Наследование таблиц, это большое и несколько медленное по сравнению с классами SQL LINQ 2.Мы также проверили, что это как-то связано с «InheritanceDiscriminator», потому что если вы удалите его, производительность будет хорошей.

Последующие вызовы быстрые и, похоже, что-то кэшируют в локальном хранилище потоков.Есть ли способ сохранить это в нескольких потоках?

Answer 1

По вашему коду видно, что вы предлагаете добавить новый подкласс для каждого клиента. Это, к сожалению, не будет работать из-за внутренней проблемы перфорации L2S. Рано или поздно у вас будет , чтобы отказаться от этого подхода. Вы также можете легко узнать, какая функция вызывает проблему, запустив приложение под нагрузкой (удерживайте F5) и несколько раз остановить отладчик. Посмотри, где он останавливается чаще всего.