ADO.NET vs BDP.NET Performacetest?

[Christof]

Hallo,

ich habe mal Performacemessungen zwischen den beiden Zugriffsarten und etwas erstaunliches festgestellt.

Datenmenge 15466 Datensätze mit einem SELECT DISTINCT von 1.143.396 Datensätze

Den selben SQL Befehl habe ich mit...
...ADO.NET mit dem DataReader und anschliessend füllen einer ComboBox mit den Einträgen
...BDP.NET mit DataAdapter und DataSet an eine ComboBox gebunden

Also der Vergleich zwischen einem DatenAdapter und einem direkten DatenReader.

ADO.NET BDP.NET Zeit in Sekunden!
MSSQL 1.718 2.109
Firebird 7.812 6.578

Beim MSSQL war wie ich es erwartet habe da der BDP ja nicht direkt darauf zugreift.

Aber beim Firebird warum ist der BDP Provider schneller als per ADO.NET ??????

Das würde ja dann für die Benutzung des BDP.NET Providers bei Firebird sprechen.
Das Ergebnis ist ja das selbe die ComboBox ist gefüllt und genau das will ich.
Kann ich mir nicht erklären, kann das jemand anderes ?


Gruß
Christof

[Christof]

Hat hier niemand ein Statement dazu ?

[Robert_G]

Zitat von Christof:

Hat hier niemand ein Statement dazu ?

Was soll man dazu sagen?
Meine Meinung zum BDP kennst du sicher. Den würde ich noch nichtmal nehmen, wenn er 10-mal schneller wäre.
Beim FireBird Provider kann man aber etwas tricksen.
Ich habe zum Beispiel in einer statischen HashTable vorkompilierte FbCommands gehalten. Da Firebird keinen richtigen Client hat, wird ja der Query plan und die Berechtigungsprüfung nicht wiederverwendet.
Als Index der HashTable habe ich einfach den Typ der Klasse genommen. Das Statement aus dem "Pseudo cache" hat es ganz gut beschleunigt.

[Christof]

Zitat von Robert_G:

Zitat von Christof:

Hat hier niemand ein Statement dazu ?

Was soll man dazu sagen?
Meine Meinung zum BDP kennst du sicher. Den würde ich noch nichtmal nehmen, wenn er 10-mal schneller wäre.
Beim FireBird Provider kann man aber etwas tricksen.
Ich habe zum Beispiel in einer statischen HashTable vorkompilierte FbCommands gehalten. Da Firebird keinen richtigen Client hat, wird ja der Query plan und die Berechtigungsprüfung nicht wiederverwendet.
Als Index der HashTable habe ich einfach den Typ der Klasse genommen. Das Statement aus dem "Pseudo cache" hat es ganz gut beschleunigt.

Aha deshalb ist das so langsam, hast du dafür einen Beispielcode ?

[Robert_G]

Du weißt doch sicher was eine HashTable ist.
Und was FbCommand.Prepare() macht solltest du auch wissen.

[Christof]

Zitat von Robert_G:

Du weißt doch sicher was eine HashTable ist.
Und was FbCommand.Prepare() macht solltest du auch wissen.

Klar.
Du speichert also die

Klasse | Ergebnis auf FbCommand.Prepare()

Habe ich das richtig verstanden ?


Gruß
Christof

[Robert_G]

Zitat von Christof:

Zitat von Robert_G:

Du weißt doch sicher was eine HashTable ist.
Und was FbCommand.Prepare() macht solltest du auch wissen.

Klar.
Du speichert also die

Klasse | Ergebnis auf FbCommand.Prepare()

Habe ich das richtig verstanden ?

Klasse| Command

Das Command wird im statischen Constructor vorkompiliert und kann dann in jeder Instanz verwendet werden. Dieser Ansatz ist praktisch, aber NICHT thread safe!