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

← →
Anatoly Podgoretsky © (2007-07-13 11:55) [40]

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

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

По количеству записей вопросов нет. :-D

Есть вопрос по скорости чтения результатов запроса... Ну или копированию этих результатов в массив...

ЗЫ. Данные выбираются ВСЕ. Это точно. Про баги с RowCount я знаю и проверял на начальном этапе....
ЗЗЫ. tfield выключил. DisableControls добавил. Немного ускорилось. Добавил к периоду неделю с приемлемой скоростью. За это СПАСИБО.

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

> Это типичный однонаправленный набор данных

Это он использует его как однонаправленный.

А сам НД вполне может у него быть и двунаправленным, о чем он вероятно не подозревает и не задумывается.

Оттого и "тормоза" ощутимые (если не сказать основные) добавляются, плюс ко всем тем очевидным "кривостям" и неоптимальностям в коде, что он привел)

← →
wsv © (2007-07-13 12:00) [43]

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

fuelin:array of double;

setlength (fuelin, rowcount);

while... do begin...end

← →
wsv © (2007-07-13 12:03) [44]

> плюс ко всем тем очевидным "кривостям" и неоптимальностям
> в коде, что он привел)

Попробуйте еще как-то оптимизировать цикл while do begin end...
:-D

← →
sniknik © (2007-07-13 12:05) [45]

> fuelin:array of double;
> setlength (fuelin, rowcount);
> while... do begin...end
ошибка. с учетом уже приведенного, у тебя теряется 2 записи. если конечно принять что курсор локальный и данные выбираются все сразу.

← →
sniknik © (2007-07-13 12:06) [46]

> Попробуйте еще как-то оптимизировать цикл while do begin end...
я приводил то что оптимизирует этот цикл... только в данном случае конечно, но...

← →
wsv © (2007-07-13 12:06) [47]

> ошибка. с учетом уже приведенного, у тебя теряется 2 записи.

> ЗЫ. Данные выбираются ВСЕ. Это точно. Про баги с RowCount
> я знаю и проверял на начальном этапе....
>

← →
wsv © (2007-07-13 12:07) [48]

> я приводил то что оптимизирует этот цикл... только в данном
> случае конечно, но...
>

Эта реплика была не вам.

Вам:

> ЗЗЫ. tfield выключил. DisableControls добавил. Немного ускорилось.
> Добавил к периоду неделю с приемлемой скоростью. За это
> СПАСИБО.

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

> wsv © (13.07.07 11:59) [41]

Если известно максимальное кол-во записей, которое может оказаться в НД в рез-те выборки по известным критериям, следующие рекомендации наверняка устранят основные "тормоза":

1. Открыть однонаправленный НД.
2. Расчитать минимально необходимое кол-во памяти, необходимое для организации массива, куда будут считываться данные из НД. Выделить память.
3. В цикле while not eof do..next пройтись по НД от начала до конца, считывая данные из НД наиболее оптимальным способом и тут же подсчитывая число записей.
4. Имея фактическое число записей расчитать фактически используемую в массиве память и реаллокировать память под массив, уменьшив ее до фактического размера.

← →
sniknik © (2007-07-13 12:12) [50]

wsv © (13.07.07 12:06) [47]
это к чему? потерять всего 2 записи типа для статистики неважно?
потому как если бы данные выбирались не все то потери шли бы на 0 - 98% от общего количества, в зависимости от исходного обьема.

> Эта реплика была не вам.
какая разница кому? теперь то ты говоришь
> Попробуйте еще как-то оптимизировать цикл while do begin end...
а пример подобной оптимизации уже был.

← →
Anatoly Podgoretsky © (2007-07-13 12:30) [51]

> wsv (13.07.2007 12:00:43) [43]

С массивом порядок, дальше по выше приведенным рекомендация.
Однонаправленный набор, вывести инварианты за цикл, цикл сделать For и т.д.
На каждом шаге проводить измерение, что бы понять помог шаг или нет.

← →
Anatoly Podgoretsky © (2007-07-13 12:31) [52]

> Сергей М. (13.07.2007 12:08:49) [49]

Пункт 4 у него выполнен до цикла.

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

> Anatoly Podgoretsky © (13.07.07 12:31) [52]
>
> > Сергей М. (13.07.2007 12:08:49) [49]
>
> Пункт 4 у него выполнен до цикла.
>

Я это понимаю.

Но прогрессирующие "тормоза" могут быть связаны только с одним - с перераспределением BMM-памяти при каждой итерации, что ведет к ее интенсивной дефрагментации и, как следствие, прогрессирующим замедлением работы BMM.

← →
Anatoly Podgoretsky © (2007-07-13 12:53) [54]

> Сергей М. (13.07.2007 12:40:53) [53]

прогрессирующие "тормоза" вызываются двунаправленным курсором.

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

> Anatoly Podgoretsky © (13.07.07 12:53) [54]

Не исключено, что на стороне Zeos-клиента использование этого курсора опять же сводится к массированному перераспределению памяти.

← →
Anatoly Podgoretsky © (2007-07-13 13:27) [56]

> Сергей М. (13.07.2007 12:56:55) [55]

Все может быть, на Zeos часто ругаются, в том числе и за скорость

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

А таки любопытно, есть ли в Мускуле IBUDF-подобный механизм..

Гуглить, честно скажу, лень)

Просветите вкратце, кто в курсе ?

> Сергей М. (13.07.2007 13:40:57) [57]

MySql это несколько тысяц опубликованых версий

> Johnmen © (13.07.07 14:29) [59]

> дельфисты отдыхают

Ну глянул я на это чудо)

Да, вижу:

Чтобы механизм UDF работал, функции должны быть написаны на C или C++

Копнул чуть глубже.
Вижу что это заявление слишком громкое)

> Мне не интересно

Мне тоже.
Ибо любопытство удовлетворил и сделал вывод - сабж возможен, и он по механизму аналогичен IB

ВСЕМ СПАСИБО ЗА ПОНИМАНИЕ И ПОМОЩЬ, ЧОУЖ...
Разбил выбранный период на интервалы. Испытания показали, что данные за неделю (а это, по максимуму, 24 часа х 120 записей в час х 7 дней = 20800 записей) выбираются приемлемо быстро. Поэтому целый период делим на 7 дней, выбираем понедельно, потом остаток от нецелой недели. При каждом переходе в новый интервал "обнуляю" и переизмеряю массивы. Получилась своего рода "подкачка" при выборке данных.
При этом увидел плюсы:
1. При обработке добавил возможность остановить обработку, если получнные в рез-те обработки данные УЖЕ удовлетворяют, то дальше, по application.messagebox yes/no, делаем вывод о необходимости продолжения обработки.
2. Тот злополучный прогрессор теперь кажет процесс так как он есть, что говорит юзеру о том, что программа не зависла, а продолжает работать.

> При каждом переходе в новый интервал "обнуляю" и переизмеряю
> массивы.

1. Зачем массив обнулять, если новые данные его просто перепишут? Для верности?
2. Если тебе известно максимально возможное кол-во данных за неделю, зачем изменять размер?
Один раз выделяешь массив максимального размера и все, дальше используешь Arr[0] to RowCount....

> Тот злополучный прогрессор теперь кажет процесс так как он есть

Тебе не предлагили отказаться от прогрессбара. Предлагали сделать размер прогрессбора например RowCount div 100.
Далее if CurrentRow div 100 = 0 then pb.StepBy(1);
Это все твои тормоза.
Ну и самое важное, тебе все говорят про однонаправленный курсор, зачем игнорируешь?

to wsv ©
Проблема та же...
но есть отличия - всё гораздо хуже, поэтому хотелось бы больше подробностей.
>>что данные за неделю (а это, по максимуму, 24 часа х 120 записей в час х >>7 дней = 20800 записей) выбираются приемлемо быстро.
У неприемлимо медленно:

13000 - 37 секунд, 26200 - 153, 39600 - 362

Времена варьируюься в зависимости от мощности компьютера и mysql-сервера (localhost -задержка в доли секунды, DSL - десятки секунд).
Подробностями в данном случае я подразумеваю тип процессора, объём RAM, версию SQL и Zeos, размер строки таблицы и т.п.

to atruhin
>>Это все твои тормоза.

Совершенно не верно. Например, у меня запрос выполняется в отдельном потоке, соотв. ничего кроме чтения массива там нет. При этом система полностью загружена.

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