Opakované volanie query proti načítaniu hodnôt z objektu je rovnako rýchle

[Stanislav Hruška]

V pôvodnom riešení som pre výpočet niektorých hodnôt volal samostatné query.
Teraz mám tri query nad celým setom údajov. To zbehne rýchlo.
Potom nastavujem parametre pre ďalší query. Generuje to 3150 záznamov.
Pôvodné riešenie - tu som volal tie samostatné query. Samostatné query sú volané 1 200 krát.
Terajšie riešenie - pracujem s hodnotami, ktoré mám uložené v objekte.
.
Ostal som veľmi prekvapený, že sa čas akosi nezmenil. Robil som to len kvôli tomu. Bol som presvedčený, že pôjde rapídne dole.
DB (FB) je lokálna embeded. To je vykonanie SQL a načítanie hodnoty z neho také rýchle ako načítanie hodnoty z objektu?
Je pravda, že tam mám dva cykly. Tie majú maximálne do 3 opakovaní.

[Stanislav Hruška]

To volanie query je 1 950 krát.
Meranie času pri objekte je tiež divné. Má rozptyl vyše sekundy. Trvá zhruba 4 - 5 sekúnd. Je to viacnásobné volanie po sebe. Bez zmeny podmienok.
Pri meraní času na zistenie časov používam Now().

[Jirka]

Pri meraní času na zistenie časov používam Now().

Pokud máš knihovnu JCL  můžeš použít TJclCounter

[pf1957]

To volanie query je 1 950 krát.
Meranie času pri objekte je tiež divné. Má rozptyl vyše sekundy. Trvá zhruba 4 - 5 sekúnd. Je to viacnásobné volanie po sebe. Bez zmeny podmienok.
Pri meraní času na zistenie časov používam Now().

Tvoje uloha neni jediny bezici proces, pocinaje CPU a konce RDBMS je rada nelinearit v podobe vyrovnavacich pameti atd. Pokud to chces zrychlit, tak potrebujes najit bottle neck a na to se soustredit.

BTW, co se ti nezda na 4 s / 2000  = ~ 2 ms/dotaz? To je u DB docela slusny cas.

[Stanislav Hruška]

Jirka: JCL nepoužívampf1957: Ja to myslím opačne. Prečo nie je verzia s cyklickým SQL pomalšia ako priamy prístup do objektu?

[pf1957]

Ja to myslím opačne. Prečo nie je verzia s cyklickým SQL pomalšia ako priamy prístup do objektu?

No proto jsem ti na to neodpovidal, protoze na to se neda na zaklade informaci, ktere jsi poskytl, odpovedet. Ty  to mas na stole a muzes zjistit, nad cim to travi kolik casu... Na to nema smysl se ptat

[Jirka]

Jirka: JCL nepoužívam

Můžeš zkusit prostředky Delphi
https://delphi.programmingpedia.net/en/tutorial/2425/time-intervals-measurement

[Jirka]

Jirka: JCL nepoužívam

Můžeš zkusit prostředky Delphi
https://delphi.programmingpedia.net/en/tutorial/2425/time-intervals-measurement

Tady to máš hezčí od Radka
https://delphi.cz/post/Delphi-2010-StopWatch.aspx

[Stanislav Hruška]

Na to nema smysl se ptat

Ja som si to viacmenej myslel. Presedel som nad tým celý a výsledok je diskutabilný. Popravde, neviem presné časy pri cyklických sql. Robil som vždy len jedno meranie a bolo prakticky 5 sek.
Na odkazy sa pozriem.

[Stanislav Hruška]

Tak som skúsil ten StopWatch. Má vyššiu presnosť, čo ma nezaujíma.
Ukazuje mi menší rozptyl, ale vyššie hodnoty.
Ďakujem zaň.

[Jirka]

Presedel som nad tým celý a výsledok je diskutabilný. Popravde, neviem presné časy pri cyklických sql. Robil som vždy len jedno meranie a bolo prakticky 5 sek.

Tak použij ten StopWatch , nechej si vracet průběžné časy v milisekundách které zapíšeš do Tlist<> a po ukončení všech cyklů si můžeš Tlist vypsat třeba s názvy Query do listboxu

[Stanislav Hruška]

Ja už s tým nemienim nič robiť.
Pôvodné riešenie som už vyhodil. Aj keď ho mám v zálohe a nebolo by to technicky ťažké dostať späť. Nie je to tak zaujímavé, aby som sa v tom hrabal.
Určite bude nové riešenie o niečo rýchlejšie, keď DB bude niekde na serveri. Ak bude
Keď zoberiem do úvahy, že to je 3150 cyklov/záznamov a pre každý záznam sa vypočítava hodnota, aj keď iba Record.čosi1 * Object.čosi2, tak to nie je až tak zlé. DB to spracuje v 1 - 2 desatinách sekundy.