Мастера DELPHI (документация, исходники, скачать)

Основная («Начинающим»)/ Базы / WinAPI / Компоненты / Сети / Media / Игры / Corba и COM / KOL / FreePascal / .Net / Прочее / RSDN.ORG

« предыдущая ветвь | форум | следующая ветвь »

Вопрос в ускорении расчёта. [D6, XP]

Страницы: 1 2 3 >
Drowsy © (2012-01-10 07:17:00)
В базе данных до фига небольших по количеству, но "длинных" записей таблиц.
Расчётный алгоритм связан с активной навигацией по датасетам этих таблиц.
Вопрос в ускорении расчёта.
Например, если работать не с датасетами, а со связанными списками записей, ускорит ли это расчёт?

Dennis I. Komarov (2012-01-11 16:19:00) [1]

> может он там матрицы решает вместе с нейросетями :)

ага, тапочки ухихикались... :)

Jeer (2012-01-11 10:40:00) [2]

> Dennis I. Komarov © (11.01.12 01:28) [41]
>
> Я к тому что, либо зашить целиком алгоритм обработки данных
> на сервер(а-ля хранимка)

Мы знать не знаем, что у него за алгоритмы - может он там матрицы решает вместе с нейросетями :)

OW (2012-01-11 10:19:00) [3]

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

ну да, лучше так
я еще в хранимках так делал
begin -- proc
set DT = getdate()
...
exec WriteToLog 'NameProc', DT, getdate()
end -- proc

имеем таблу, аля NameProcess BeginTime EndTime
потом выборками разными определяем, что чаще запускается, когда, сколько в среднем, сколько в среднем в зависимости от времени суток(нагрузки) и т.п.

Inovet (2012-01-11 09:29:00) [4]
> [43] Inovet © (11.01.12 09:28)
> в самой процедуре

в самих процедурах

Inovet (2012-01-11 09:28:00) [5]
> [42] OW © (11.01.12 08:50)
> > Вот как бы оценить, какая процедура занимает больше всего
>
> > времени в потоке расчёта..
>
> самое простое - обрамить вызовы в
> TC := GetTickCount;

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

OW (2012-01-11 08:50:00) [6]

> Вот как бы оценить, какая процедура занимает больше всего
> времени в потоке расчёта..

самое простое - обрамить вызовы в
TC := GetTickCount;
RunProcedure;
ShowMessage(ToStr(GetTickCount - TC));
показать время выполнения в тиках

для правильных результатов требуется многочисленная прогонка. Словом, аля [6]

Dennis I. Komarov (2012-01-11 01:28:00) [7]
Я к тому что, либо зашить целиком алгоритм обработки данных на сервер(а-ля хранимка) и получать результат как есть, либо получить входящие данные из БД и мучить их на стороне клиента. Но не дергать/менять данные на каждую итерацию с СУБД, ибо костер ИМХО...

Jeer (2012-01-11 01:07:00) [8]

> СУБД не должен страдать за итерационные методы

Та ну ?
Т.е. бизнес-логика, перенесенная на сервер должна ограничиться 2*2 ?
Щас !

Кто-то и что-то сказал, что в случае вопроса ТС, его проблемы должны решать СУБД, алгоритмы или мы с вами ?

"То-то и оно" (С) АП.

Dennis I. Komarov (2012-01-11 00:46:00) [9]

> Я шо-то не пойму, ко мне какие вопросы ?
> Если кратко - СУБД страдает за то, шо она хорошо может делать.

СУБД не должен страдать за итерационные методы... это не его карма, даже если у него это хорошо получается, собственно вопросы только эти... :)

Jeer (2012-01-11 00:29:00) [10]

> Что мешает свалить это на сервер?

Може и Религия :)

Я шо-то не пойму, ко мне какие вопросы ?
Если кратко - СУБД страдает за то, шо она хорошо может делать.

Dennis I. Komarov (2012-01-10 23:51:00) [11]

> в процессе расчёта надо показывать промежуточные результаты
> итераций.

на зачем?

> Затем начинаем ее решать итерациями.

Что мешает свалить это на сервер?
Или уж получите входные данные для алгоритма из БД и издевайтесь над ними как угодно, но СУБД то почему должен страдать?

Jeer (2012-01-10 22:39:00) [12]

> И все это делается на стороне клиента?

Не вижу проблем.

Прежде всего - Задача.

Затем начинаем ее решать итерациями.

Где окажемся ? И даже не знаю - это конкретика.

Может свалим на сервер, может поделимся с ним, а может останемся на клиенте - такое решение достигается не сразу, но достигается, если голова "варит".

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

В конце концов, чередуя "размышлизмы" с тестами, обретаем спокойствие в виде "просчитанной" и "оттестированной" архитектуры.

Дальше ? "Обычный" кодинг.

Drowsy (2012-01-10 22:36:00) [13]

> Dennis I. Komarov © (10.01.12 21:56) [34]

в процессе расчёта надо показывать промежуточные результаты итераций.

Dennis I. Komarov (2012-01-10 21:56:00) [14]

> - они занимают 45 машинописных листов, но, в основном тупые
> арифметические действия с данными и коэффициентами из таблиц.
>

И все это делается на стороне клиента? Разжигайте костер!!!

Drowsy (2012-01-10 21:44:00) [15]
Вот как бы оценить, какая процедура занимает больше всего времени в потоке расчёта..

Drowsy (2012-01-10 21:29:00) [16]

> Anatoly Podgoretsky © (10.01.12 17:56) [28]

Кроме этого, всё, вроде бы, понятно.
Если речь пошла об алгоритмах расчёта, то
- они занимают 45 машинописных листов, но, в основном тупые арифметические действия с данными и коэффициентами из таблиц.
- ясно, что последует совет искать "слонов" в архитектуре и организации расчёта, как справедливо говорит Jeer.

Anatoly Podgoretsky (2012-01-10 21:11:00) [17]
> Jeer (10.01.2012 20:24:30) [30]

Да не только количества испугался, а также, что они говорят какие то
непонятные слова.

Jeer (2012-01-10 20:24:00) [18]

> Anatoly Podgoretsky © (10.01.12 18:00) [29]

Пока не будет от ТС внятного пояснения проблем с "расчетами" - можно долго медитировать на Ктулху.
Однако, похоже, ТС сильно испугался такого наплыва советчиков и слинял.

Anatoly Podgoretsky (2012-01-10 18:00:00) [19]
Еще есть мастер-детайл связи, эффект еще более драматичен.

Anatoly Podgoretsky (2012-01-10 17:56:00) [20]

> > а есть ли в коде .DisableControls?
>
> Нет, все убраны.

Там не написано DisableDbAwareControls

Страницы: 1 2 3 >

Наверх

	« предыдущая ветвь \| форум \| следующая ветвь »