Performance TpFIBDataset

[DeddyH]

Dann muss ich mich leider ausklinken. Hansa, übernehmen Sie

[nachti1505]

@ DeddyH
Schade, trotzdem DANKE

[BerndS]

Hallo,
ich verwende nie FieldByNumber sondern
Dataset.Fields[index].As...

Warum verwendest du nicht die fibquery, wenn diese so schnell ist???
Das FibDataset nimmt man doch nur, wenn die Datensätze gepuffert werden müssen, um zurück kommen zu können.

Gruß Bernd

[nachti1505]

So, nochmal eine Zusammenfassung:

Delphi-Quellcode:

var 
  Dataset: TpFIBDataset; 

begin 
  Dataset.First; 
  while NOT Dataset.Eof do begin 
    for i := 0 to 9 do begin 
      Dataset.Fields[i].AsString; 
    end; 
    Dataset.Next; 
  end; 
end;

Das ganze ist einfach nur eine Routine, um die Geschwindigkeit des Auslesens von 10 Feldern zu testen, weswegen der resultierende String auch zu nichts zugewiesen wird. Am Dataset hängen keine Sources, Komponenten etc.!

Der Query fragt aus der Datenbank (Adressen) alle Felder der Tabelle ab. In der Tabelle befinden sich ca. 3500 Einträge.

Performance
TpFIBDataset: ~35000 ms
TpFIBQuery: 4600 ms
JvUIBQuery: 600 ms

Also signifikante Unterschiede.

Auf die JvUIB hab ich zum Laden verzichtet, da sich die JvUIBTransaction imho nicht mit der TpFIBTransaction synchronieren lässt.

Workaround für mich um passable Geschwindigkeiten zu erreichen:

1) Begrenzen der Abfrage auf 500 Datensätze
2) Nutzen des pFIBQuery aus dem pFibDataset
Dataset.QSelect.Fields[i].AsString Vielen Dank an alle Mitdiskutierenden.

BTW: Erstaunlich, dass eine OS-Komponente (JvUIB) schneller ist, als eine kommerzielle (FIBPlus). Trotzdem sind mir die FIBs bequemer

[exilant]

Zitat von nachti1505:

So, nochmal eine Zusammenfassung:
Performance
TpFIBDataset: ~35000 ms
TpFIBQuery: 4600 ms
JvUIBQuery: 600 ms

Verstehen tue ich das nicht. Ich fülle hier eine doppelt verkettetet Liste mit > 4.000 Einträgen aus einem tpFibdataset (23 Columns) dem ein Query mit ziemlich heftigen Joins zugrunde liegt.
Die verwendeten Tabellen haben zwischen 12.000 und 15 Mio. rows.
Ausführungszeit des Querys (tpfibdatsat.active := true) mit anschliessendem iterieren durch das Ergebnis incl. Aufbau der Datenstruktur dauert < 1,5 Sec.

Firebird 2.0.1 SuperServer/Linux
Delphi 2007 bzw. Delphi 5 (gleich schnell)


Deine Angabe mit den 35.000ms macht mir daher zu schaffen. 35.000 ms bei 3.500 Datensätzen ergibt lächerliche 10 Records/sec. Da muss was faul sein.

[nachti1505]

Gib mir doch mal bitte ein Codeschnipsel, wie du durch das Dataset iterierst. Hast du evt. irgendwelche speziellen Optionen im Dataset angeschalten oder abgeschalten? Spielt vielleicht die Transaktion auch noch eine Rolle?

BTW: Was mir aufgefallen ist, wenn die pFIBDatabase lokal läuft (Programm läuft auf dem Server) gibt es einen unheimlichen Geschwindigkeitszuwach gegenüber einer Remotevariante (127.0.0.1:C:\Programme\Firebird_2_1\Datenbank.fdb )...

[exilant]

Zitat von nachti1505:

Gib mir doch mal bitte ein Codeschnipsel, wie du durch das Dataset iterierst. Hast du evt. irgendwelche speziellen Optionen im Dataset angeschalten oder abgeschalten? Spielt vielleicht die Transaktion auch noch eine Rolle?

Delphi-Quellcode:

// dsActiveOrders ist ein tpFibdataset (ein tpFibquery würde es genauso tun,
// hat historische Gründe)

dsActiveOrders.active := true;

while not dsActiveorders.eof do begin
  currentEntry := mylist.addentry;
  currententry.id        := dsActiveOrders.fieldbyname('id').asinteger;
  currententry.StackId   := dsActiveOrders.fieldbyname('stackid').asinteger;
  currententry.StockId   := dsActiveOrders.fieldbyname('stockid').asinteger;
  currententry.Status    := dsActiveOrders.fieldbyname('status').asinteger;
  currententry.Partitial := dsActiveOrders.fieldbyname('partitial').asstring;
  currententry.Orderdate := dsActiveOrders.fieldbyname('orderdate').asdatetime;
  ...
  ...
  dsActiveOrders.next;
end; 
currententry.next := NIL;
dsActiveorders.active := false;

Das war's schon. Nichts besonderes. Das Dataset hat eine eigene Transaktion (autostart).

Zitat von nachti1505:

BTW: Was mir aufgefallen ist, wenn die pFIBDatabase lokal läuft (Programm läuft auf dem Server) gibt es einen unheimlichen Geschwindigkeitszuwach gegenüber einer Remotevariante (127.0.0.1:C:\Programme\Firebird_2_1\Datenbank.fdb )...

Dazu kann ich nichts sagen. Ich habe hier nur mit entfernten Datenbanken auf Linux Servern zu tun.

[Hansa]

Du hast das Stringgrid als Fehlerursache ausgeschlossen. Ich nicht und Test gemacht : Ergebnis : Anhang.

[nachti1505]

Mhhh, was dein Test und vorallem das Sleep(3000) nun mit einem StringGrid zu tun hat, erschließt sich mir nicht wirklich.

In meinem letzten PerformanceTest habe ich ja nicht mal mehr ein StringGrid benutzt, sondern einfach nur beliebige 10 Dataset.Fields[i].AsString aufgerufen.

Mein letzter Verdacht bezieht sich nun auf meine FIB-Version. Bin immer noch TRIAL-User. Ist es vllt.möglich, dass Devrace die TRIAL von der Performance her beschränkt hat???

[Hansa]

Zitat von nachti1505:

...das Sleep(3000) nun mit einem StringGrid zu tun hat, erschließt sich mir nicht wirklich.

Schwierig, was ? Das Stringgrid ist völlig aussen vor. Nicht das das bei dir doch noch irgendwo rumschwirrt. Das sleep (3000) zeigt lediglich, wer oder was für die Dauer von 3 Sek. verantwortlich ist. Nämlich nicht etwa über 20000 Datensätze, sondern nur das sleep !!

Zitat von nachti1505:

Mein letzter Verdacht bezieht sich nun auf meine FIB-Version. Bin immer noch TRIAL-User. Ist es vllt.möglich, dass Devrace die TRIAL von der Performance her beschränkt hat???

So blöd sind sie nun wirklich nicht. Es ist schon schlimm genug, wie manche Leute die Performance trotz aller Vorsichtsmaßnahmen irgendwie doch so gebremst kriegen, dass sie sogar denken, die Komponenten wären das schuld. 8)