Ich zum Beispiel h�tte bei ExecuteScalar (2) vs. ExecuteReader (3) gewettet da� es anders rum ausgeht. Wie ich das Resultat gesehen habe, hab' ich ildasm.exe angeworfen und mir den Sourcecode von MS f�r ExecuteScalar angesehen... interessant, interessant (ich hatte auf eine etwas andere Implementierung in ExecuteScalar gesetzt).
Auch interessant ist die Wahl der Anzahl der Loops (measurements.cs ist nicht im Download mit dabei) �ber die 4 Varianten. Zb bei 100 Loops ist v2 schneller als v1, bei 1000 ist es aber umgekehrt. Bei 100 Loops, aufsteigend: v4, v3, v2, v1 Bei 1000 Loops: v4, v1, v3, v2 Klarerweise regeneriere ich die SqlCommands, was man normalerweise nicht machen w�rde. Aber trotzdem irgendwie interessant (die Netzwerkroundtrips fangen bei h�heren Durchlaufzahlen eine wichtigere Rolle zu spielen an). Chris At 09:03 PM 12/5/2001 +0100, you wrote: >Netter Artikel, > >Aber die Regel kurzer Code = schneller Code ist doch wohl hoffentlich >nicht weit in den K�pfen der Programmierer verbreitet oder ? Hoffe ich >mal :) > >-----Urspr�ngliche Nachricht----- >Gesendet: Mittwoch, 5. Dezember 2001 20:50 >An: aspDEdotnet >Betreff: [aspdedotnet] Performanceartikel > > >http://www.aspheute.com/artikel/20011206.htm > >Ich habe mich heute kurz mal ge�rgert, da� es keine guten Hilfsmittel >zur >Performancemessung gibt... worauf ich dann in den Untiefen von >System.Web.Util (�ber den TraceContext von ASP.NET) eine gute Idee fand >und >neu implementiert habe. [btw, vTune war mir um eine # zu gro�] > >Nettes Nebenbeiresultat: Performancestats rund um Single-Value Results >in >ADO.NET. > >Chris | [aspdedotnet] als [email protected] subscribed | http://www.dotnetgerman.com/archiv/aspdedotnet/ = Listenarchiv | Sie k�nnen sich unter folgender URL an- und abmelden: | http://www.dotnetgerman.com/listen/aspDEdotnet.asp
