Замедление DataSet.next

← →
wsv © (2007-07-13 10:28) [0]

Здравствуйте.
Столкнулся с проблемой при больших DataSet-ах с доступом к MySql с помщью компонентов Zeos.
В DataSet (точнее ZQuery, который наследник DataSet), выбирается большое количество данных, 50 тысяч строк и более.
При считывании результата запроса циклом while...do begin ... Dataset.next... происходит замеделение считывания, которое визуально отловлено простым прогрессором.

КАК ИЗБАВИТЬСЯ?

Может можно как-то другими способами скопировать результат в массив?

В частном случае копируются данные типа duoble в масив соотв. типа... В общем случае это вариантные данные.

← →
Ega23 © (2007-07-13 10:34) [1]

зачем тебе 50 000 записей на клиенте?????

← →
Johnmen © (2007-07-13 10:34) [2]

> выбирается большое количество данных, 50 тысяч строк и более.

Зачем иметь сразу столько данных на клиенте?

← →
sniknik © (2007-07-13 10:49) [3]

> while...do begin ... Dataset.next... происходит замеделение считывания, которое визуально отловлено простым прогрессором.
имхо, все дело в волшебных пузырьках... т.е. точках, next не причем.
хотя, не зная особенностей Zeos, могу и ошибаться.

> КАК ИЗБАВИТЬСЯ?
исправить ошибку. сначала, а после задуматься "а нафига тебе столько данных на клиенте?" (если не исправить то притормаживание просто "смажется" малым количеством... останется но не будет так заметно)

← →
Desdechado © (2007-07-13 10:59) [4]

Данные читаются и накапливаются. Вот и замедление. Используй однонаправленный датасет, если уж припекло читать столько много.

← →
wsv © (2007-07-13 11:01) [5]

> Зачем иметь сразу столько данных на клиенте?

> зачем тебе 50 000 записей на клиенте?????

Это навигационные данные, которые поступают каждые 15-30 секунд.
Нужен отчет за период.
Границы периода неизвестны. Данные нужно обработать сначала.

← →
Desdechado © (2007-07-13 11:03) [6]

> Нужен отчет за период. Границы периода неизвестны.
"Принеси то, не знаю что?"

> Это навигационные данные, которые поступают каждые 15-30 секунд.
А причем тут отчет?

← →
Сергей М. © (2007-07-13 11:04) [7]

> Данные нужно обработать сначала

Почему бы не обработать их на стороне сервера ?

← →
wsv © (2007-07-13 11:07) [8]

> "Принеси то, не знаю что?"

Период конечно известен. Это наше время. В общем случае - год-два-три...

> А причем тут отчет?

Отчет при том, что нужно сначала отловить обработкой заправки-сливы-остановки-стоянки, что уже сделано. На данных до 30 тыс. строк обработка (считывание+собственно поиск) занимает меньше секунды. Дальше, только передача данных из запроса в массив занимает уже десятки секунд. Например на 100 тыс записей - это 18 секунд передачи в массив.

Как выйти из положения?

← →
wsv © (2007-07-13 11:08) [9]

> Почему бы не обработать их на стороне сервера ?

Ога... Вейвлет преобразование и фильтрация силами Мускула? :-D

← →
sniknik © (2007-07-13 11:11) [10]

> Как выйти из положения?
общеизвестный выход из положения - родить. ;о)
в твоем случае разродиться исходной информацией... (сам, я так понимаю, ошибку найти не в состоянии)

← →
Сергей М. © (2007-07-13 11:12) [11]

> Вейвлет преобразование и фильтрация силами Мускула?

Почему бы и нет ?

Я не в курсе, но разве Мускул не предоставляет механизма использования внешних пользовательских функций, подобного механизму UDF в IB ?

А если и не предоставляет, то все равно непонятно, нафига каждый раз тащить все даннные, а не только вновь поступившие..

← →
Плохиш © (2007-07-13 11:16) [12]

> Дальше, только передача данных из запроса в массив занимает
> уже десятки секунд. Например на 100 тыс записей - это 18
> секунд передачи в массив.

Ну а что хотели, дай догадаюсь, постоянные перераспределения размеров массива. Производительность современных вычислительных систем в любом случае конечна, а вы тут такие объёмы данных по системе таскаете...

← →
wsv © (2007-07-13 11:17) [13]

Исходная информация. D7-Zeos-MySql.
Навиг. данные: очень частая пилА - топливный датчик, показания с которого нифига не интегрированы.
1. Получаем данные датчика за период.
2. Загоняем в массив.
3. Преобразуем вейвлетом.
4. Линеаризуем.
5. Приводим к тарировке датчика
6. Ищем сливы-заправки
7. Выводим график расхода по тарировке и вероятные сливы-заправки.

Проблема в п.2
Все остальное очень быстро робит.

← →
wsv © (2007-07-13 11:18) [14]

> нафига каждый раз тащить все даннные, а не только вновь
> поступившие..

не все. за период, указанный юзером.

← →
sniknik © (2007-07-13 11:21) [15]

> Исходная информация. D7-Zeos-MySql.
это не то ... интересуют "волшебные пузырьки" в коде их [0], а именно как делаешь то что по твоему тормозит.

← →
wsv © (2007-07-13 11:24) [16]

> а именно как делаешь то что по твоему тормозит.

i:=0;
dm.navdata.First;
while i<RowCount do
begin
fuelout[i]:=dm.navdata.fieldbyname("....").Value;
dm.navdata.Next;
inc(i);
pb.StepBy(1);
end;

← →
wsv © (2007-07-13 11:25) [17]

А можно как-то по другому?
Вот и спрашиваю, чо... :-D

← →
sniknik © (2007-07-13 11:26) [18]

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

← →
wsv © (2007-07-13 11:27) [19]

Контролов связанных с датасетами нет вообще.
Все в массивах.

← →
Сергей М. © (2007-07-13 11:27) [20]

> не все. за период, указанный юзером

Откуда тогда взялось значение RowCount ?

← →
wsv © (2007-07-13 11:30) [21]

> Откуда тогда взялось значение RowCount ?

Блин... :-D
dm.navdata.close;
dm.navdata.sql.text:="Select ... from ... where...";
dm.navdata.open;

rowcount:=dm.navdata.rowcount;

:-D

← →
sniknik © (2007-07-13 11:30) [22]

ага, ну вот [16], более менее
отключения контролов нет, RowCount поменяй на not eof, fieldbyname вынеси за пределы цикла, и StepBy делай не на каждую итерацию, а на видимую часть (видиш к примеру 100 квадратиков в прогрессе, рассчитай так чтобы было 100 StepBy)
изменилось чтонибудь?

← →
wsv © (2007-07-13 11:35) [23]

> fieldbyname вынеси за пределы цикла

Это как? :-)
можно сделать fieldvalues или fields.field[0]... но как "вынести за цикл"?

> RowCount поменяй на not eof

Делал. Тоже самое.

← →
Сергей М. © (2007-07-13 11:37) [24]

> rowcount:=dm.navdata.rowcount

Я не в курсе, что там творится в потрохах Zeos, но глубоко сомневаюсь, что RowCount вернет истинное число записей в выборке.

← →
wsv © (2007-07-13 11:38) [25]

> отключения контролов нет,

> Контролов связанных с датасетами нет вообще.

Есть еще вариант разбить заданный период и/или выкинуть точки, неудовл. определенным условиям. например, нули, т.е. где сигнала не было. но после этого нужно будет запоминать откуда их выкинули и добавлять обратно в массив.

← →
Плохиш © (2007-07-13 11:39) [26]

> wsv © (13.07.07 11:35) [23]
>
> > fieldbyname вынеси за пределы цикла
>
> Это как? :-)
> можно сделать fieldvalues или fields.field[0]... но как
> "вынести за цикл"?

var
tmpField: T<xxx>Field;
...
tmpField := dm.navdata.fieldbyname("....");
while not dm.navdata.eof do
....

← →
wsv © (2007-07-13 11:39) [27]

> RowCount вернет истинное число записей в выборке.

Возвращает правильно. Сомневаться не приходится, ибо инвалид поинтер оперэйшен... :-)

← →
Desdechado © (2007-07-13 11:40) [28]

> но как "вынести за цикл"?
FieldByName возвращает указатель на поле. Сохрани его до цикла. Это сильно влияет на скорость. Потом просто в цикле будет указатель.As...

Кроме того мне не понятно, зачем еще раз данные читать в массив, если они уже есть в датасете (тот же массив).

и окружить всё в
dm.navdata.DisableControls; try // Твой код finally dm.navdata.EnableControls; end;

PS. Тормознутые эти zeos, я бы перешёл на адо :-)

> Это как? :-)
> можно сделать fieldvalues или fields.field[0]... но как "вынести за цикл"?
var
Fld: TField;
begin
Fld:= dm.navdata.fieldbyname("....");
while i<RowCount do
Fld.Value;

у многих получение индекса поля по имени расчетное... т.е. тратит время.
> RowCount поменяй на not eof
> Делал. Тоже самое.
это просто более правильно, но когда писал не было этого
> rowcount:=dm.navdata.rowcount;
тут тебе можно просто for i:= 0 to ... поставить, этот цикл быстрее изза другого рода проверки выхода (а она каждый раз не нужна т.к. судя по всему рекордсет локальный)

а StepBy? возьми просто убери прогресс и засеки общее время, и контнролы отключи обязательно даже если их нет (проверка может быть на разных уровнях вложенности, отключенные тобой это самый первый уровень, быстрее всего)

> Кроме того мне не понятно, зачем еще раз данные читать в
> массив, если они уже есть в датасете (тот же массив).

Представь если еще бегать при линеаризации, тарировке и поиске заправок и сливов по датасету... :-D
Именно поэтому и массивы.

> PS. Тормознутые эти zeos, я бы перешёл на адо :-)
точно знаеш? работал?

> Возвращает правильно

С чего ты так уверен ?

Last после открытия НД ты явно не делаешь, делает ли это неявно Zeos ты тоже не знаешь, предоставляет ли эту "фичу" сам Мускул - тебе тоже неведомо..

> Сомневаться не приходится, ибо инвалид поинтер оперэйшен

Чевой-то ?)

> Представь если еще бегать при линеаризации, тарировке и поиске заправок и сливов по датасету... :-D
а если не бегать? если составить запрос на обьеденение так чтобы все рядом было?

> С чего ты так уверен ?

Потому што при заполнении массива нет ошибок.

> sniknik © (13.07.07 11:44) [32]
> > PS. Тормознутые эти zeos, я бы перешёл на адо :-)
> точно знаеш? работал?

Хотел перейти, начитавшись рекламы :-) Переделал проект с адо на зеос и время обработки увеличилось в 4 раза, покрутил ещё там чего-то немного и забросил. Теперь пользуюсь стандартными проверенными технологиями :-)

> а если не бегать? если составить запрос на обьеденение так
> чтобы все рядом было?

Данные тарировки физически лежат в другой базе. На этапе разработки они просто загнаны в мемо (их около 10 строк всего). Они тоже читаются в массивчик и входные данные тарируются клиентом.

А с чем объединить еще, я не знаю. :-D

> Потому што при заполнении массива нет ошибок.
а с чего им быть если rowcount вернул частичное значение количества на еще не полностью скачанном рекордсете, массив ты сформировал по этому размеру и перенос сделал по нему же, не обращая внимания что данных уже больше.
(я вообщето подумал что у тебя клиентский курсор, наподобие в ADO, и данные приходят все без докачек...)

> Потому што при заполнении массива нет ошибок

А с какого перепугу они должны возникнуть ?

Открыв НД ты тут же прочитал св-во RowCount, пребывая в святой уверенности в том что получил действительное число записей в этом НД, после чего выделил соответствующую память под массив. Где здесь "криминал" ? Нету его) ... Засада же может поджидать тебя с совершенно иной сторона - число записей в НД в реальности больше, чем то что ты получил вот таким макаром.

Это типичный однонаправленный набор данных!
И определение массива не приведено.

Замедление DataSet.next Найти похожие ветки