Parallel.ForEach и набор таблиц

@ramonafalls · Регистрация: 05.06.2013

Студворк — интернет-сервис помощи студентам

Здравствуйте. Итак, есть процедура, которая возвращает набор таблиц (10 и больше), которые потом использую для вывода в гриды на форме и для выгрузки в эксель. Изначально запихивала этот набор в DataAdapter, а затем - в DataSet. Но по времени заполнение датасета из адаптера занимает минимум три минуты (для минимального набора таблиц), что видно при отладке. Желая повысить производительность, пытаюсь использовать Parallel.ForEach, но никак не могу понять, как мне правильно определить делегат (в итоге lst не заполняется):

C#
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
SqlCommand ReportPL = new SqlCommand("exec [Analiz_FP] " + plyear + "," + pl_per_b + "," + pl_per_e + ",'" + plkod_lpu + "','" + plprofil + "','" + plsk + "','" + pdisp + "','" + ptip + "','" + pldet + "'," + ppartiya + "," + pmon_b + "," + pmon_e + ",'" + pvid + "'", fp1conn);
                ReportPL.CommandTimeout = 10000000;
                try
                {
 
                    var lst = new List<System.Data.DataTable>();
                     Parallel.ForEach(lst, (datatable) =>
                     {
                         using (SqlDataReader reader = ReportPL.ExecuteReader())
                         {
                             while (reader.Read())
                             {
                                 datatable.Load(reader);
                                 lst.Add(datatable);
                             }
                         }
                     });
lst.ForEach(reportDS_p.Tables.Add);
}
catch{}

Либо я вообще не в той степи, и можно организовать этот цикл по-другому?
Алсо, может, кто-то подскажет более эффективные способы загнать эти таблицы в датасет?

@ramonafalls · 07.07.2017, 14:41 **[ТС]**

Usaga, В режиме отладки я наблюдала отдельно за временем выполнения процедур и за временем заполнения датасета. Отсюда и такие данные. Это не по моим предположения, это реальный тест - три с лишком минуты выполнялась процедура, затем заполнился адаптер, а затем еще около трех минут отладчик висел на da.Fill(ds). В адаптере уже были данные из выполненной процедуры. Значит, это какой-то косяк самого заполнения датасета. Может, он еще какие-то махинации совершает в это время..но мне это кажется бредом.

HF, да, в этой процедуре как раз вызываются процедуры, дающие те самые 12 таблиц. Но, как я уже писала выше, если экзеки даже не пихать в одну процедуру, в коде в VS вызывать каждую и результат каждой записывать отдельно в датасет, то результат по времени выигрывает всего на несколько секунд. Да, процедуры надо пересмотреть, хотя, я на данный момент постаралась уйти от всяких вложенных запросов и операторов типа in, оставив агрегатные функции и джойны(как переработать их, я пока не могу придумать)-все равно, время выполнения не менее 10 сек. Понятно, что 10+процедур -это уже 1,5 минуты и более на выполнение. А тут еще и датасет заполняется столько же или в два раза дольше. так что. хотелось начать с малого и сначала как-то разобраться с датасетом.

Добавлено через 7 минут
Кстати, может ли быть такая задержка в заполнении датасета связана с тем, что все это дело выполняется в отдельном потоке?

@HF · 07.07.2017, 20:13

Есть два решения на две проблемы в случае использования тяжёлых (длительных) процедур, больших таблиц (много строк) и где результат - не одна таблица, а много
1) Биндинг. По рекомендации, требуется перед использованием Fill, отключать все события связанные с привязкой и обработкой, потом биндинг снова подключать.

C#
1
2
3
bindingSource.RaiseListChangedEvents = false // перед загрузкой
// .. Fill
bindingSource.RaiseListChangedEvents = true // после загрузки

2) и конечно же SQL-Plan. То что вы делаете в ManagementStudio полностью отличается от того что делается в адаптерах, т.к. там разные подключения и настройки. Вкратце - из-за того, что база пытается постоянно построить новый план на наш запрос, то происходят очень большие задержки с выдачей результата. Единственным ешением является, но не всегда это помогает: добавить во все процедуры команду

SQL
1
SET ARITHABORT OFF

.

2.1) Я ещё добавлял команду

SQL
1
OPTION (RECOMPILE)

Так как это тоже влияет на статистику и планы. В случае постоянного изменения результатов, база ещё и начинает статистику вычислять и неверно. Так как вызываются разные процедуры (через EXEC), то это как бы накладывает на результат какую-то неведомую злую магию. А эта опция, по сути берёт весь результат, и создаёт конечную одну статистику по всему результату.

Добавлено через 2 минуты
Интернет забит этим вопросом (почему медленно) и ответами связанными с этими двумя командами. Вот даже большая статья на эту тему для очень любопытных: Slow in the Application, Fast in SSMS?

@Usaga · 08.07.2017, 04:39

HF, я ну оооочень сомневаюсь, что процедуры отрабатывают медленно из-за построения плана запроса))) Да и с биндингами, хоть и хороший совет, но не сильно уместный, как мне кажется. ТС заявила, что процедуры отрабатывают несколько минут. Т.е. проблема уже на уровне БД. И явно не в плане запроса.

Тут только профилировать выполнение процедур и смотреть какая (или какие) процедура работает медленно и потом попытаться понять почему.

Всё остальное - рекомендации наугад.

Не по теме:

Но решение с распараллеливаеним, конечно, позабавило) В чём проблема? Да фиг знает! Давай в параллель запрос выполнять)))

Новые блоги и статьи Все статьи Все блоги /
Саморегулирующийся социальный контракт для сервера cross-section. Hrethgir 14.08.2026 С кодом конечно таких глубоких размышлений пока не было, впрочем я уже привык к алгоритмизации. Суть предмета записи: снова в диалоге с нейросетью (я взял пока себе ник для учётки админа - Rector). . . .	Часы электронные Uhbif79 12.08.2026 Выкладываю программу часов. Программа позволяет: 1. Использовать системное время и дату, 2. Есть возможность вводить время и дату вручную. 3. Реализованы 2 будильника: начало и конец рабочего дня. . . .	Часы с будильником на основе класса QLCDNumber Uhbif79 12.08.2026 Всем добрый день, выкладываю программу часов с будильником на основе класса QLCDNumber. Здесь я пробовал самостоятельно создавал классы, впервые столкнулся с видимостью переменной одного класса из. . .	Установка MinGW GCC 16.2 и CMake 8Observer8 10.08.2026 VK Видео: https:/ / vkvideo. ru/ video-240781534_456239017 YouTube: eY5-5PyI9NM Текстовая версия
Неделя из жизни имитационной модели склада: мои кривые руки растут, откуда надо anaschu 10.08.2026 Неделя из жизни имитационной модели склада: как я почти написал неправильную логику и что с этим делать Работаю сейчас над учебно-рабочим проектом: строю в AnyLogic имитационную модель процессов. . .	Калькулятор для расчета родства russiannick 07.08.2026 1. Задача: Создать калькулятор для расчета родства. Родственных связей существует 8 ступеней, такие как: p - отец P - мать q - муж Q - жена b - брат B - сестра s - сын S - дочь	Мир по моей воле kumehtar 07.08.2026 Когда-то кажется, что всё просто. Ты весь такой светлый. Причиняешь добро. Борешься за справедливость в этом тёмном мире. Потом начинаешь замечать одну неприятную вещь. Почти каждый хороший. . .	Кредитный калькулятор Maks 05.08.2026 Решение задачи по прикладной информатике средствами 1С. Задача: Напишите приложение-калькулятор, которое помогает рассчитывать параметры кредита для аннуитетного и дифференцированного видов. . .

@ramonafalls 0 / 0 / 0 Регистрация: 05.06.2013 Сообщений: 21
	07.07.2017, 14:41 [ТС]
	Usaga, В режиме отладки я наблюдала отдельно за временем выполнения процедур и за временем заполнения датасета. Отсюда и такие данные. Это не по моим предположения, это реальный тест - три с лишком минуты выполнялась процедура, затем заполнился адаптер, а затем еще около трех минут отладчик висел на da.Fill(ds). В адаптере уже были данные из выполненной процедуры. Значит, это какой-то косяк самого заполнения датасета. Может, он еще какие-то махинации совершает в это время..но мне это кажется бредом. HF, да, в этой процедуре как раз вызываются процедуры, дающие те самые 12 таблиц. Но, как я уже писала выше, если экзеки даже не пихать в одну процедуру, в коде в VS вызывать каждую и результат каждой записывать отдельно в датасет, то результат по времени выигрывает всего на несколько секунд. Да, процедуры надо пересмотреть, хотя, я на данный момент постаралась уйти от всяких вложенных запросов и операторов типа in, оставив агрегатные функции и джойны(как переработать их, я пока не могу придумать)-все равно, время выполнения не менее 10 сек. Понятно, что 10+процедур -это уже 1,5 минуты и более на выполнение. А тут еще и датасет заполняется столько же или в два раза дольше. так что. хотелось начать с малого и сначала как-то разобраться с датасетом. Добавлено через 7 минут Кстати, может ли быть такая задержка в заполнении датасета связана с тем, что все это дело выполняется в отдельном потоке? 0

@Usaga 14727 / 9503 / 1362 Регистрация: 21.01.2016 Сообщений: 35,830
	08.07.2017, 04:39
	HF, я ну оооочень сомневаюсь, что процедуры отрабатывают медленно из-за построения плана запроса))) Да и с биндингами, хоть и хороший совет, но не сильно уместный, как мне кажется. ТС заявила, что процедуры отрабатывают несколько минут. Т.е. проблема уже на уровне БД. И явно не в плане запроса. Тут только профилировать выполнение процедур и смотреть какая (или какие) процедура работает медленно и потом попытаться понять почему. Всё остальное - рекомендации наугад. Не по теме: Но решение с распараллеливаеним, конечно, позабавило) В чём проблема? Да фиг знает! Давай в параллель запрос выполнять))) 0

Опции темы