Вопрос в ускорении расчёта.

← →
Drowsy © (2012-01-10 07:17) [0]

В базе данных до фига небольших по количеству, но "длинных" записей таблиц.
Расчётный алгоритм связан с активной навигацией по датасетам этих таблиц.
Вопрос в ускорении расчёта.
Например, если работать не с датасетами, а со связанными списками записей, ускорит ли это расчёт?

← →
Омлет © (2012-01-10 09:27) [1]

1. Прямой доступ к памяти всегда быстрее.
2. Код в студию.

← →
OW © (2012-01-10 09:35) [2]

если мало записей, и они неизменны,
может, просто создавать массив и работать с ним?

а есть ли в коде .DisableControls? Порой забываешь про него, а с ним скорость уже приемлимой становится, без дальнейших телодвижений

← →
Jeer © (2012-01-10 09:36) [3]

> Вопрос в ускорении расчёта.

Вопрос в архитектуре, а Ваш вопрос - ее следствие.

← →
Jeer © (2012-01-10 09:45) [4]

> а есть ли в коде .DisableControls?

Если нет связанных DBAware, то и метод не нужен.

← →
OW © (2012-01-10 09:51) [5]

> Если нет связанных DBAware, то и метод не нужен.

Уверен?

← →
OW © (2012-01-10 10:16) [6]

точно не помню где не проверяется, как-то находил, потом забыл где именно, только помню вывод. А он таков: ставить всегда, есть или нет DBAware или что-то еще. Не важно. Ставить.
Проверка:
var i: Integer; BoolDC: Boolean; DC, NDC: Cardinal; TC: Cardinal; begin aq1.Open; DC := 0; NDC := 0; for i := 0 to 999 do begin aq1.EnableControls; BoolDC := (i mod 2 = 0); if BoolDC then aq1.DisableControls; TC := GetTickCount; aq1.First; while not(aq1.Eof) do begin aq1.Next; end; if BoolDC then DC := DC + GetTickCount - TC else NDC := NDC + GetTickCount - TC; end; ShowMessageFmt("DisCtrl %d -- NoDisCtrl %d",[DC, NDC]);

656 vs 1204 тика

← →
sniknik © (2012-01-10 10:45) [7]

>> Если нет связанных DBAware, то и метод не нужен.
> Уверен?
уверен что нужен... (для ADO точно), проверка через "внешний объект" гораздо тяжелее отсутствия оной.

← →
Drowsy © (2012-01-10 10:57) [8]

> Jeer © (10.01.12 09:36) [3]
> Вопрос в архитектуре

архитектуре чего?

← →
Drowsy © (2012-01-10 11:00) [9]

> а есть ли в коде .DisableControls?

Нет, все убраны.
луук-ап и калкулс полей в датасетах тоже нет.

← →
OW © (2012-01-10 11:00) [10]

> sniknik © (10.01.12 10:45) [7]

я и говорю,
там где то стоит попытка уведомления контрла о смене активной записи
похоже у TDataSet (или TDataLink - забыл)
даже если контрла нет. т.е. аля если не задисэйблено, то попытаться уведомить бла-бла.. В процессе бла-бла выясняется, что уведомить некого, но попытка состоялась и время отнято.

← →
OW © (2012-01-10 11:01) [11]

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

а надо поставить :)

← →
RWolf © (2012-01-10 11:06) [12]

> OW © (10.01.12 11:01) [11]

D7, db.pas:
procedure TDataSet.DataEvent(Event: TDataEvent; Info: Longint); ... begin NotifyDataSources := not (ControlsDisabled or (State = dsBlockRead)); ... if NotifyDataSources then begin for I := 0 to FDataSources.Count - 1 do TDataSource(FDataSources[I]).DataEvent(Event, Info); if FDesigner <> nil then FDesigner.DataEvent(Event, Info); end; end;
если к датасету не присоединено ни одного DataSource, смысла запрещать контролы не видно.

← →
Drowsy © (2012-01-10 11:14) [13]

> OW © (10.01.12 11:01) [11]
>
>
> > > а есть ли в коде .DisableControls?
> >
> > Нет, все убраны.
>
> а надо поставить :)

ну да, поставлены. )

← →
Drowsy © (2012-01-10 11:14) [14]

> луук-ап и калкулс полей в датасетах тоже нет.

в смысле - убраны. )

← →
OW © (2012-01-10 11:16) [15]

> RWolf © (10.01.12 11:06) [12]

сходу тоже не нашел
но тем не менее практические проверки (код из [6], например) упрямо говорят, что есть смысл

← →
OW © (2012-01-10 11:21) [16]

> Drowsy ©

если мало записей, и они неизменны (очень мало изменяемые),
может, просто создавать массив(ы) и работать с ним(и)?

>> Расчётный алгоритм связан с активной навигацией по датасетам этих таблиц.
что за расчеты, кстати?
можно ли код?

← →
RWolf © (2012-01-10 11:25) [17]

> OW © (10.01.12 11:16) [15]
> > RWolf © (10.01.12 11:06) [12]сходу тоже не нашелно тем
> не менее практические проверки (код из [6], например) упрямо
> говорят, что есть смысл

прогнал код на локальной базе Firebird 1.5, таблица из 68 тыс. записей, выборка одного поля.
результаты совпадают в пределах погрешности.

← →
OW © (2012-01-10 11:33) [18]

> RWolf © (10.01.12 11:25) [17]

М-да?..
А компоненты какие?

← →
RWolf © (2012-01-10 11:34) [19]

> [18]

FIBPlus 6.9.6.

← →
sniknik © (2012-01-10 12:41) [20]

> FIBPlus 6.9.6.
> уверен что нужен... (для ADO точно), проверка через "внешний объект" гораздо тяжелее отсутствия оной.

FIBPlus это COM объект?

← →
Ega23 © (2012-01-10 12:55) [21]

> RWolf © (10.01.12 11:06) [12]
>
> если к датасету не присоединено ни одного DataSource, смысла
> запрещать контролы не видно.

http://delphimaster.net/view/3-1235739432
Особенно [7].

← →
OW © (2012-01-10 13:17) [22]

Проверил на ODAC, (TOraDataSet) - нет разницы
значит, ADO (com-объекты) только этим грешит.
значит, на TDataSet зря грешил. Спутал с TAdoDataSet, наверное.
Но все равно, отключить - хуже не будет. Неизвестно через чего ТС работает.

← →
RWolf © (2012-01-10 13:19) [23]

> Ega23 © (10.01.12 12:55) [21]

да, в TCustomADODataSet логика использует ControlsDisabled в условии обращения к COM-серверу; запрещать контролы нужно.

← →
Ega23 © (2012-01-10 13:21) [24]

> Но все равно, отключить - хуже не будет. Неизвестно через
> чего ТС работает.

Во-во, я после той ветки на воду всегда дую. Хотя казалось бы...

← →
Jeer © (2012-01-10 14:03) [25]

> Во-во, я после той ветки на воду всегда дую.

Ну а я, поскольку давно забил на АДО и проверил данный функционал для всех используемых мной технологий доступа, ленюсь вписывать две строчки :)
Хотя, спорить не буду - *.Disable*, .*Enable.*, это универсальный подход.

← →
Jeer © (2012-01-10 14:12) [26]

> Drowsy © (10.01.12 10:57) [8]
>
>
> > Jeer © (10.01.12 09:36) [3]
> > Вопрос в архитектуре
>
> архитектуре чего?

Архитектуре разрабатываемой Вами программной системы.

Архитектура - это комплекс принятых для реализации технических решений (технологий), [организационных мероприятий] по хранению, обработке и визуализации данных для максимально полного удовлетворения заданного функционала системы в оговоренной прикладной сфере. (С) Jeer

← →
Jeer © (2012-01-10 14:13) [27]

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

Есть еще датасеты в памяти, файлы в памяти.. :)

← →
Anatoly Podgoretsky © (2012-01-10 17:56) [28]

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

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

← →
Anatoly Podgoretsky © (2012-01-10 18:00) [29]

Еще есть мастер-детайл связи, эффект еще более драматичен.

← →
Jeer © (2012-01-10 20:24) [30]

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

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

← →
Anatoly Podgoretsky © (2012-01-10 21:11) [31]

> Jeer (10.01.2012 20:24:30) [30]

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

← →
Drowsy © (2012-01-10 21:29) [32]

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

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

← →
Drowsy © (2012-01-10 21:44) [33]

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

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

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

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

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

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

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

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

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

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

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

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

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

на зачем?

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

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

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

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

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

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

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

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

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

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

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

Я к тому что, либо зашить целиком алгоритм обработки данных на сервер(а-ля хранимка) и получать результат как есть, либо получить входящие данные из БД и мучить их на стороне клиента. Но не дергать/менять данные на каждую итерацию с СУБД, ибо костер ИМХО...

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

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

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

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

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

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

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

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

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

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

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

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

Вопрос в ускорении расчёта. Найти похожие ветки