Rychlost ADO a jiné offtopic příběhy

vložil Radek Červinka 13. října 2011 00:46

Jsa v podezření, že ADO není tak rychlé jak někdo tvrdí, jal jsem se do toho trochu šťouchat. Vzniklo to tak, že bych rád zrychlil zobrazení dat v gridu a že mne zajímalo, zda existuje grid, který by načetl z DB jen ty data, která jsou viditelná. Věděl jsem, že něco takového musí existovat, jelikož všechny EMS SQL Managery pro různé DB to umožňují - aspoň částečně (data jsou asi načtena po viditelný záznam, tj. při stránkování při PgDown jsou asi načteny všechny stránky až po aktuální stránku). A věděl jsem že to je napsané v Delphi (stačí vyhledat řetezec Delphi v EXE).

Update: Zdeněk Vašků mi poradil nastavit u uniquery ve SpecificOption FetchAll (true/false) + přímo v komponentě FetchRows (počet vět v dávce). A to pak funguje i normálního gridu. Viz komentáře.

Nakonec mne napadlo podívat se do exe a zkusit tam vyhledat text "grid" - předpokládal jsem, že komponenta bude mít ve jménu tento řetězec a Delphi při kompilaci ukládá do EXE názvy všech komponent. Problémem je, že exe je šifrované asprotect, což je celkem efektivní ochrana. Takže smůla - tolik času jsem tomu nechtěl věnovat. Už jsem se na to chtěl vykašlat, když mne napadlo, že by stálo možná za to v tomto případě udělat dump běžícího procesu. A tady jednou MS zabodoval. Windows 7 mají ve správci procesů možnost zapsat dump do souboru (to mi řekl google), takže stačilo přes pravé tlačítko na procesu vybrat "Vytvořit soubor výpisu" (to je teda překlad) a na disku se objevil dump (jedná se o výpis procesu - není to spustitelný soubor, ale dá se v tom vyhledávat. To píši také protože aby si laskavý čtenář uvědomil, že když něco zabalí např. UPX tak to neznamená, že pokud je tam heslo jako čitelný text, že si nějak pomůže.

No výsledkem je TcxGrid což je grid od devexpress, který je ale na mne drahý. Takže jsem si řekl, zda nezkusím aspoň zrychlit data.

Už z dřívějška jsem věděl, že existují komponenty SDAC (resp. UniDAC) od devart.com a už pár lidí mi říkalo, že to není vůbec špatné. Mají i další výhodu - UniDAC umožňují přístup k libovolné databázi včetně FireBirdu nebo ODBC (kdyby to MS opravdu s OLEDB zabalil), což je pro mne plus. Stáhnul jsem si trial verzi a že zkusím pár testů. Prima je, že součástí je i celkem inteligentní grid (ale nedá se koupit samostatně, zato ho dostanete i se zdrojovým kódem).

CrGrid

Takže jsem na formulář vrazil TADOConnection, TADODataset, TUniQuery a TUniConnection plus nějaké DataSource a TDBGrid a uvedený TCRGrid, v DB vytvořil tabulku a nageneroval jsem tam 460tisíc záznamů a jal se testovat.

Nejprve jsem položil dotaz v MS Management Studio Express 2005 - výsledek 10s. Stejný dotaz v uvedeném EMS SQL Manageru - 5,8s. Což mne začalo zajímat. Přes ADO v Delphi XE2 - 5,7s, přes UniDAC nakonec za 2,7s. Což opravdu není špatné. Všechny doby jsou do konce zobrazení gridu s daty.

Volba gridu na to nemá vliv (tedy pokud u TCrGridu nezapnete sumarizaci).

Další možnou volbou je AnyDAC, které jsem netestoval, ale podle názorech na fórech to může být i někdy o kapánek rychlejší (a podporované DB jsou taky zajímavé). Každopádně tam mají i porovnání rychlostí i s BDE a DBExpress (obojí rychlejší než ADO).

Závěr: je dobré vědět, že ADO opravdu není tak rychlé, ale je zadarmo. UniDAC a AnyDAC nabízejí zajímavou placenou alternativu.


Nabízíme Delphi školení a konzultace na různá témata, primárně ve Vaší firmě.

Tagy: , ,

Komponenty

Komentáře

13.10.2011 11:40:58 #

Zdeněk Vašků

Za sebe mohu říci, že UniDAC případně specializovaná alternativa od DevArt (dříve CoreLab) se zatraceně vyplatí. Třeba v případě Oracle (který není v Delphi Professional) určitě. Jinak pro Oracle s TUniQuery do DevExpress gridu 300 tisíc vět najednou cca 15 s. Pokud se načte jen prvních 300 tak první zobrazení gridu 0.5 s + následně čas při scrollování.

Zdeněk Vašků

13.10.2011 11:45:35 #

Karel Janeček

Přesně tak, souhlasím s kolegou výše. Loni jsem přešel na SDAC a posléze i na ODAC a zkušenosti jsou výborné - spektrum komponent je mnohem širší (zejména samostatná Transaction) a u mě rychlost zobrazení dat v mřížce o cca 31% vyšší oproti ADO. Ceny je velmi rozumná, po nákupu SDAC jsem dostal slevu 50% na nákup ODAC. Řešení technických dotazů je v řádu hodin, myslím že dobrá volba.

Karel Janeček

13.10.2011 11:52:15 #

Karel Janeček

Ještě mě napadá v souvislosti s DBGridem - již roky používám rDBGrid od svého dvorního dodavatele komponent a troufám si tvrdit, že nic lepšího a rychlejšího na trhu není. Třeba NEdatovou mřížku má bezkonkurenční TMS, ale jejich datová varianta je v zásadě nepoužitelná.

rDBGrid je současně doplněn i tzv. Actions, které umožňují přímo v rámci mřížky hledat, filtrovat, tisknout, exportovat atd. atd. Myslím, že to nebude bráno jako reklama (nejsem v ničem zaniteresován, jen spokojen) - podrobnosti na www.rosinsky.cz nebo mohu sdělit vlasztní zkušenosti pomocí emailu na www.yamaco.cz.

Jinak ještě další informace - pokud někoho štve (podobně jako mě štvaly) neužitečné DescriptionPane a ComponentPane v Object Inspectoru v D2010 a XE, dotčený dodavatel mi připravil DPK balíček, který je odstraňuje a zbude tak více místa na Properties a Events. Zájemci opět nechť kontaktují Ing. Rosinského.

Karel Janeček

13.10.2011 12:20:27 #

Radekc

>Pokud se načte jen prvních 300 tak první zobrazení gridu 0.5 s + následně čas při scrollování.

Jak se to udělá?
>ad rDBGrid
díval jsem se a má tam napsané jen D2010, jak to je s XE2?

Radekc

13.10.2011 12:25:05 #

bullhead

Dělal jsem +-2roky zpět testy Unidac versus Anydac a Andac (přijmenším tehdy) nebyl ani ZDALEKA tak rychlý jako Unidac.

Ještě pro info - verze BEZ sourcecode (tu mám koupenou) NEmá žádný grid (ale používám ve spojení z TMS DB Gridem a naprostá spokojenost).

B.

bullhead

13.10.2011 12:45:15 #

Karel Janeček

to Radekc: Chtělo by to dotázat se přímo u dodavatele, pro XE funguje vše OK, je tedy předpoklad, že bude fungovat i pro XE2 (samozřejmě neuvažuji FM-alespoň prozatím) - ale raději se prosím zeptejte u zdroje.

Karel Janeček

13.10.2011 12:59:04 #

Vladimír klaus

@Radek:

U DevEx cxGridu, resp. GridView existuje DataController.DataModeController.GridMode:=true;

Pak se mřížka stane hloupou (neumí seskupovat, filtrovat, řadit...), ale je pekelně rychlá, protože načítá jen omezené množství dat. Omezené množství je stanoveno nějak inteligentně nebo pomocí

DataController.DataModeController.GridModeBufferCount

Vladimír klaus

13.10.2011 13:02:31 #

Zdeněk Vašků

>>Pokud se načte jen prvních 300 tak první zobrazení gridu 0.5 s + následně čas při scrollování.
>Jak se to udělá?

U uniquery je ve SpecificOption FetchAll (true/false) + přímo v komponentě FetchRows (počet vět v dávce).
U TcxGridu se musí v DataControlleru v DataModeController nastavit GridMode.

Většinou používám kombinaci clientdataset-provider-uniquery, takže většinou FetchAll, ale občas se to hodí načítat postupně.

Zdeněk Vašků

13.10.2011 13:20:57 #

Radekc

>@Bullhead

No podle http://www.devart.com/unidac/editions.html je mřížka i ve std. edici a ta je BEZ zdrojáků  

>@ Vasku
Takze to umí ten TcxGrid, skoda.

Radekc

13.10.2011 13:22:37 #

Radomír B.

Po převodu Win32 VCL aplikace z Delphi2010 do DelphiXE2 jsem zaznamenal znatelné zpomalení vykreslování formulářů, především v případě, kdy jsou na formuláři obrázky. Zkoušel jsem i triviální aplikace a zdá se to jako obecná vlastnost. Možná to souvisí se zavedením stylů. Máte někdo podobnou zkušenost nebo typ co nastavit jinak?

Radomír B.

13.10.2011 13:29:04 #

Zdeněk Vašků


>@ Vasku
Takze to umí ten TcxGrid, skoda

Pokud použiju standardní TDBGrid, tak to taky funguje.

Zdeněk Vašků

13.10.2011 13:40:46 #

Radekc

Ono to fakt funguje i s obyčejným gridem. Moc děkuji.

Radekc

13.10.2011 13:49:58 #

bullhead

>@RadekC
...ano dle jejich stránek to tak vypadá, ale já mám ofiko Unidacy, instaluje jejich instalák, a mezi komponentami neni v XE2 (a nebyl ani v XE)
B.
p.s. ...a během toho co to píšu jsme jen sescanoval instalační adresář, "CRGrid.dcu" apod. tam je = jejich instalák to nenainstaloval (nikdy jsem se po tom nepídil, grid z TMS si myslím že je top grid componenta - dělal jsem i z devexpress a TMS je rychlejší i "hezčí") ...balík Unidacu "GUI related component" je sice v instalovaných balíčcích ale NEmá žádne komponenty v sobě (maj někde chybu) ...jen pro info

bullhead

13.10.2011 13:59:37 #

bullhead

Z vlastní skušenosti ještě k Unidacu - pro mně je hlavní ta "databázová multiplatformost". Dělám z mnoha typy DB a to co poskytuje Unidac (máte jednu DB vrstvu a měníte jen providera) je úžasné (má to i Anydac ale jak jsem psal je pomalejší - předpokládám že pořád podle nějakých diskuzích co jsem viděl).

To že máte jednoho EXE klienta, na centrále firmy na X PC a je připojen na velký SQL server - a na pobočkách na starých PC je tentýž klient připojen na lokální MySQL, a vy v kódu měníte jeden řádek (dynamicky dle ini) a vše jede stejně je úžasné (je prá věci co měnit občas musíte, např. generátory ala firebird např v MSSQL nejsou, ale vše se dá obejít).

B.

bullhead

13.10.2011 17:00:00 #

Zdeněk Vašků

Dalsi vyhoda je solidni snaha o sjednoceni typu poli - integerfield, floatfield atd.
+ minimalni zavislost na dalsich dll knihovnach. Oracle to umi uplne bez klienta.

Zdeněk Vašků

13.10.2011 17:18:39 #

bullhead

...přesně tak ...čisté EXE (ostatně proto vyvíjíme v Delphi ne, safra kdo už převede 7z do PASu:-)) ...obrázek co krásně ilustruje co vše a jak unidac umí:
http://www.devart.com/unidac/images/unidacdiagram.jpg

bullhead

15.10.2011 9:09:02 #

Dmitry Arefiev

Hello All

At first my apologizes for writing on english.

1) According to our benchmarks AnyDAC TADQuery fetch-all-records operation is about 2.5 times faster than TADOQuery with SQL Server. So, the rough estimation for Radik test is 2-3 secs for TADQuery. Also, I have no idea, what was the setup for TADOQuery, TUniQuery. Although, there is not much options in dbGo, there are many in UniDAC and AnyDAC. Let say with MARS turned Off, MSSQL default cursor, larger RowsetSize, etc you will get best possible fetch performance with AnyDAC.

2) But still fetch-all will be involved. With TADTable and Live Data Window mode, there will be no fetch-all involved and the ADTable.Last will be very fast. Also TADTable is capable to navigate through large datasets without overloading memory. So, TDBGrid + TADTable + large DB table should work fast and without consumed a lot of resources.

Dmitry Arefiev

6.12.2011 23:37:29 #

Radekc

>BullHead

IBDAC std. edition - tj bez zdrojáků
grid je

"c:\Program Files (x86)\Devart\IBDAC for RAD Studio XE2\Source\CRGrid.pas"

Je to volitelná položka v instalátoru.

Radekc

Komentování ukončeno

Naše nabídka

Partial English version.

MVP
Ing. Radek Červinka - Embarcadero MVP
profil na linkedin, Twitter:@delphicz

Nabízím placené poradenství a konzultace v oblasti programování a vývoje SW.
Dále nabízíme i vývoj speciálního software na zakázku.

Neváhejte nás kontaktovat (i ohledně reklamy nebo burzy práce).

Pokud chcete podpořit tento server libovolnou částkou, můžete použít PayPal. Moc děkuji.

Delphi Certified Developer

O Delphi.cz

Delphi je jediný moderní RAD nástroj podporující tvorbu nativních aplikací pro platformu Win32, Win64 , Mac OSX a na iPhone a Android (s výhledem na další platformy díky FireMonkey) na současném trhu (včetně Windows 8.1).

V současnosti je světová komunita přes dva miliónů vývojářů.

Delphi.cz je nezávislý portál pro uživatele Delphi. Portál není koncipován pro úplné začátečníky, i když i ti se zde nebudou nudit, ale spíše na programátory, kteří již něco znají a chtějí své znalosti dále rozvíjet a sledovat novinky.

Anketa

Poslední komentáře

Comment RSS