Jag har gjort lite prestandatester mellan dataset, datatable och datareader och jag har lite funderingar som jag skulle vilja dela med mig av.
Testbakgrund:
Jag hämtar upp ca tio fält från tre joinade tabeller i Access. Frågan returnerar c a 2500 rader, vilka presenteras i en grid, dock inte Microsofts egna utan Componentones. Detta är en Win Forms applikation som inte har särskilt komplicerad uppbyggnad (ingen åtta lagers arkitektur ;) )
Resultaten i korthet:
- Om man använder dataset eller en datatable spelar ingen större roll, overheaden på dataset verkar vara liten. Möjligtvis kan skillnaden öka i en applikation som är mer skiktad.
- Datareadern är inte mycket snabbare än dataset/datatable om man använder GetValue metoden för att hämta data.
Naturligtvis kan man använda metoderna som är anpassade för respektive datatyp, vilket gör det hela snabbare, MEN då kastas ett exception om ett fält är Null. Lösningen på det är att först kontrollera om fältet är Null, men det tar förstås tid och frågan är hur man gör det på ett effektivt sätt. För om man inte vill fånga ett exception måste man först använda GetValuemetoden när man skall kontrollera för Null, vilket förstås förstör hela syftet. Eller har ni en bra lösning?
Jag testade också skillnaden mellan att loopa igenom ett dataset, manuellt sätta värdena i griden och att använda datasourcepropertyn. Lite förvånad märkte jag att loopandet i Componentones grid gick 15-25 % snabbare.
Det som jag är mest nyfiken på är vilken belastning som låg på serven när testet genomfördes.
Att hämta 2500 rader och lägga I ett dataset/dataTable/dataReader är inte speciellt krävande om det är det enda som händer. Prestanda problem upptäcker man nästan aldrig I utvecklingsmiljöer eftersom det inte finns någon last på maskinen.
Däremot så kommer man upptäcka prestandaproblem när man väl kommer I produktion och belastningen blir annorlunda, och då kommer även små skillnader börja markas markant.
Sedan måste man skilja på prestanda och skalbarhet, tyvärr motarbeter ofta dessa två varandara, så om man får bra prestanda så minska skalbarheten och tvärtom.
Sedan kan det också vara så att det är Access isigsjälv som sätter begräsningen.
Säg att det skall ta 10 ms att hämta 1000 rader med en datareader och det skall ta 50 ms att hämta 1000 rader med ett dataset. Medans access tar 60 ms på sig att leverera 1000 rader. Då spelare det ingen roll om du väljer ett datatset eller en datareader eftersom flaskhalsen inte ligger I de objekten utan I själva databasen.
Att genomföra prestanda tester är extremtsvårt och kommer alltid att varierar från gång till gång, då du aldrig kan få 2 exakt lika miljöer, det kan skilja lite I prestana mellan 2 likadana nätverkskort, eller mellan 2 likadanna CPU så kan de skilja I prestanda.
Generellt så väljer man objekt efter behov. Är det prestanda du måste ha så är datareadern bättre och snabbare. Är det skalbarhet så är dataTable bättre då du kan stänga din databaskoppling fortare och sedan börja bearbeta datan. Vill du har möjligheten att göra massor så väljer du ett dataset.
Tja, detta var ett enkelt test. Inte direkt vetenskapligt.
Men:
- Jag talade ju om prestandatest. Jag har ju inte nämnt skalbarhet. Det är förstås att viktigt att testa det också, men det ingick inte i mitt test, därför tog jag inte upp det.
- Naturligtvis skiljer det mellan olika hårdvara, men jag har använt samma hårdvara. Jag har förstås försökt eliminera mjukvarofaktorn genom att stänga de program och tjänster som skulle kunna störa.
På en gammal maskin (som liknar den skarpa miljön) tog hela processen med att hämta 2500 rader och lägga ut dem i griden 7 sekunder oavsett om jag använde datareadern eller datatable.
Mina tester bevisar inte att datareadern och datatablen är lika snabba, utan att under vissa förutsättningar spelar det ingen större roll om man använder datareadern eller datatablen. Man kan alltså inte ALLTID anta att datareadern alltid är det snabbaste alternativet. Det var poängen.
På en gammal maskin (som liknar den skarpa miljön) tog hela processen med att hämta 2500 rader och lägga ut dem i griden 7 sekunder oavsett om jag använde datareadern eller datatable.
Vilket får mig att inse att begränsningen knappast ligger I datareader eller datatablen utan I din datakällas förmåga att leverera data. Alltså så klara inte access av att skicka datan så fort så att du kommer märka någon skillnad om du använder dig av datatable eller datareadern.
Mina tester bevisar inte att datareadern och datatablen är lika snabba, utan att under vissa förutsättningar spelar det ingen större roll om man använder datareadern eller datatablen. Man kan alltså inte ALLTID anta att datareadern alltid är det snabbaste alternativet. Det var poängen
Tror inte jag håller med dig I din poäng, jag skulle omformulera det och säga att det finns andra flaskhalsar som påverkar mer än just valet av dataset/datareader, vilket du bevisat genom att det tar 7 sekunder att hämta 2500 rader från en databas.
En datareader kommer ALLTID vara snabbare än ett dataset, och hur kan jag påstå något sånt, ju för att ett dataset fylls av en dataAdapter som I sin tur använder sig av en datareader för att fylla datasetet. Så oberoende om du använder dig av ett dataset eller en datatable eller en datareader så används alltid en datareader för att hämta data. Och eftersom det läggs på mer overhead för att lägga datan I dataTablen och ännu mer för att lägga den I datasetet, så kommer prestandan ALLTID vara bättre att bara använda en datareader, dock kommer skalbarheten minska då man kan komma till att hålla sin databaskoppling öppen längre än nödvändigt.
OK, jag visste inte att datareadern användes i datatablen.
Just i mitt fall är flaskhalsen att trycka ut datat från dataobjektet (datareader alt datatable) till griden, inte att hämta själva datat. Jag ska testa lite mer och se vad det blir för resultat.
277 ms totalt · 4 externa anrop · v20260731065814-full.e96017d9
