SDAC Select unter XE3 sehr langsam

[OlliWW]

Hallo Zusammen,

Ich habe ein großes Software Projekt, das Datenbanken (MsSQL) benutzt. Zum Lesen und Schreiben der Daten nutze ich die SDAC Komponenten. Im Moment läuft das Projekt noch auf Delphi 2007 und ich bin gerade dabei es auf XE3 zu mirgrieren. Bei den Select-Abfragen via SDAC Pro (6.6.12) und XE3 ist mir aufgefallen, dass die Abfragen wesentlich länger dauern als unter Delphi 2007, obwohl der Code exakt der gleiche ist.

Mit ein bisschen Debugging habe ich rausfinden können, dass die Zeit beim Auslesen der einzelnen Felder verloren geht, hier ein Beispiel (Die Tabelle "Tabelle" enthält ca. 9000 Datensätze):

Delphi-Quellcode:

MSSQL1.SQL.Text := 'SELECT FIELD1, FIELD2, FIELD3, FIELD4 FROM TABELLE'
    MSSQL1.Open;
    while not MSSQL1.Eof do
    begin
      object := TMyDataObject.Create;
      object.rec_iField1 := MSSQL1.FieldByName('FIELD1').AsInteger;
      object.rec_sField2 := MSSQL1.FieldByName('FIELD2').AsString;
      object.rec_sField3 := MSSQL1.FieldByName('FIELD3').AsString;
      object.rec_sField4 := MSSQL1.FieldByName('FIELD4').AsString;
      List.Add(object);
      MSSQL1.Next;
    end; //while

MSSQL1 ist das TMSQuerry von SDAC.

Das "Open" läuft unter beiden Delphi Versionen normal schnell. Jedoch sämtliche Zuweisungen die mit "AsString" ausgelesen werden, laufen wesentlich langsamer unter XE3.
Zum Vergleich habe ich aus der Tabelle nur Zahl-Felder auslesen lassen, die man mit AsInteger auslesen lassen kann. Dort ist die Abfrage sehr performant. Die Zeitverluste treten demnach nur auf, wenn man versucht Strings per SDAC aus einer MsSQL Datenbank auszulesen. Ich habe die leise Vermutung, dass es eventuell an Unicode liegen könnte. Und so habe ich auch mal "AsAnsiString" versucht. Aber auch diese Abfragen waren nicht schneller.

Hat jemand eine Idee wie ich SDAC unter XE3 genau so performant betreiten kann wie unter Delphi 2007? Diese "kleine" Tatsache hindert mich momentan daran ein sehr großes Softwareprojekt unter XE3 weiter zu entwickeln.

[Bernhard Geyer]

Von welchen Feldtyp sind die String-Felder? varchar oder nvarchar? Der MS-SQL-Server hatte (hat?) einen Fehler das bei Wandlung von AnsiString -> Widestring sehr viel Zeit verloren geht. Unter D2007 wurde u.U. noch mit Ansistrings (bzw. varchars) auf varchar-Felder zugegriffen. Bei XE3 wird hier mit Widestrings (bzw. nvarchar) auf varchar-Felder zugegriffen.

[OlliWW]

Hallo,

Danke für die schnelle Antwort.

Die Felder sind alle Varchars im SQL 2005.

Ich habe auch versucht nur mit AnsiString lesend darauf zu zu greifen:

Delphi-Quellcode:

sField2: AnsiString;
.......
object.rec_sField2 := MSSQL1.FieldByName('FIELD2').AsAnsiString;

Das hat jedenfalls keine Besserung gebracht. Gibt es da irgendwas, was ich machen kann? Das ist ein sehr großes Projekt und dieses Beispiel mit 9000 Reihen ist eher ein kleines Beispiel, es gibt viele Stelle die mit XE3 nun so langsam sind, dass ich es keinem Kunden zumuten möchte mit einer XE3 Version meiner Software zu arbeiten. Ich möchte aber lieber gestern als heute von Delphi 2007 weg, da es nun wirklich nicht mehr zeitgemäß ist.

Würden andere Komponenten Besserung bringen? Muss ich die Tabellen konvertieren? Gibt es Einstellungen in SDAC?

[Bernhard Geyer]

Kannst du Testweise mal ein Datenbank mit nvarchars aufbauen?

[Sir Rufo]

Das gehört wohl dazu http://qc.embarcadero.com/wc/qcmain.aspx?d=111942

[OlliWW]

Hallo,

Vielen Dank für die Antworten.

Zitat von Sir Rufo:

Das gehört wohl dazu http://qc.embarcadero.com/wc/qcmain.aspx?d=111942

Das denke ich eher nicht, da es hier wirklich nur um das Auslesen von Feldern per SDAC geht, wenn ich den o.g. Code umbaue und feste Werte zuweise:
object.rec_field2 = 'Hallo';
dann funktioniert es einwandfrei.
Wenn ich nur Integer-Felder lese mit SDAC funktioniert es mit der gleichen Tabelle auch einwandfrei. Es liegt offenbar nicht nur Varchar-Feldern / String Variablen. Das Problem bestand ebenfalls auch schon vor XE3 Update 1.

Zitat:

Kannst du Testweise mal ein Datenbank mit nvarchars aufbauen?

Das habe ich gemacht. Ich habe meine Varchar-Felder einfach mit Alter Table in NVarchars verwandelt und siehe da: Es hat in der Tat die Geschwindigkeit zum positiven hin verändert, jedoch ist es trotzdem noch nicht auf dem Stand von Delphi 2007.
Ich bin mir auch nicht ganz sicher, was es für Auswirkungen hätte alle Felder in NVarchars zu ändern. Es sind mehrere 100 Tabellen mit tausenden Varchar Feldern. Allein der zusätzliche Speicherplatz der dadurch belegt werden würde, wäre m.E. nach nicht unerheblich. Ich dachte eigentlich mit XE3 wird endlich alles mal "besser" aber von Tag zu Tag kommt immer wieder der Gedanke hoch, dass ich wohl besser bei Delphi 2007 bleiben sollte

[Sir Rufo]

Niemand hat behauptet, dass das Zuweisen von festen Werten inperformant ist (nicht mal du). Wieso sollte das also jetzt langsam sein?

Der QC Eintrag bezieht sich auf den Zugriff (lesend/schreibend) auf ein TStringField /TWideStringField .

Und genau das machst du doch und bemängelst, dass es langsamer ist als unter D2007.
Die ersten Performanceeinbußen wurden schon unter XE3 festgestellt und nach dem Update 1 wurde es schlimmer (steht alles in dem QC Eintrag -> Kommentare)

Wenn du reine Integer Felder liest/schreibst und dort alles ok ist, dann hat das auch nichts mit dem QC Eintrag zu tun, denn der bezieht sich auf TStringField /TWideStringField

[Bernhard Geyer]

Zitat von OlliWW:

Das habe ich gemacht. Ich habe meine Varchar-Felder einfach mit Alter Table in NVarchars verwandelt und siehe da: Es hat in der Tat die Geschwindigkeit zum positiven hin verändert, jedoch ist es trotzdem noch nicht auf dem Stand von Delphi 2007.

Wie groß ist der Unterschied? Kannst du das mittels AQTime und Co. genau bestimmen wo Zeit verloren geht?

Zitat von OlliWW:

Ich bin mir auch nicht ganz sicher, was es für Auswirkungen hätte alle Felder in NVarchars zu ändern. Es sind mehrere 100 Tabellen mit tausenden Varchar Feldern.

Auswirkung wäre das du dein Programm weltweit verkaufen könntest und auch die Kunden hier in DE nicht nur auf das Westeuropäische Geschäft beschränkt werden wenn Sie mit deinem Programm arbeiten.

Zitat von OlliWW:

Allein der zusätzliche Speicherplatz der dadurch belegt werden würde, wäre m.E. nach nicht unerheblich.

Ich vermute mal das sein Programm nicht ein Datenbank im TB-Bereich betreibt. Dann ist der Mehrverbrauch irrelevant.

Zitat von OlliWW:

Ich dachte eigentlich mit XE3 wird endlich alles mal "besser" aber von Tag zu Tag kommt immer wieder der Gedanke hoch, dass ich wohl besser bei Delphi 2007 bleiben sollte

Ist schon vor Vorteil wenn man nicht auf die uralt Ansi-WinAPI beschränkt ist sondern alles native mit Unicode arbeiten kann.

[OlliWW]

Zitat von Bernhard Geyer:

Wie groß ist der Unterschied? Kannst du das mittels AQTime und Co. genau bestimmen wo Zeit verloren geht?

Ich habe überall im Programm Zeitmessungen, bei diesem Beispiel mit 9000 Rows dauert die Abfrage in D2007 0,5 Sekunden und in XE3 1,5.
Es gibt aber auch Stellen im Programm wo der Unterschied: 5 zu 20 Sekunden ist.

Zitat von Bernhard Geyer:

Auswirkung wäre das du dein Programm weltweit verkaufen könntest und auch die Kunden hier in DE nicht nur auf das Westeuropäische Geschäft beschränkt werden wenn Sie mit deinem Programm arbeiten.

Auch wenn das jetzt vom Thema abweicht: Die Software richtet sich ausschließlich an den deutschsprachigen Raum für eine internationalisierung der Software müssten noch ganz andere Hürden genommen werden

Zitat von Bernhard Geyer:

Ich vermute mal das sein Programm nicht ein Datenbank im TB-Bereich betreibt. Dann ist der Mehrverbrauch irrelevant.

Die Datenbanken bewegen sich zwischen 50 und 100 GB.

Zitat von Bernhard Geyer:

Ist schon vor Vorteil wenn man nicht auf die uralt Ansi-WinAPI beschränkt ist sondern alles native mit Unicode arbeiten kann.

Das stimmt schon. Das Problem ist: Mit Delphi 2007 läuft die Software super stabil und performant, wie verkaufe ich den Kunden, dass ich nun technisch mehr Vorteile habe, die für die Kunden 0,0% relevant sind, sie dafür aber spürbare Performanceeinbußen haben. Aber nun gut, das gehört ja eigentlich nicht zum Thema des Threads hier.

Ich bin gerade dabei mir eine XE2 Testumgebung aufzusetzen und werde nun die Performance mit XE2 testen. Sollten die Ergebnisse dort zufrienstellend sein könnte ich mich auch damit anfreunden das Projekt "XE3" solange zurück zu stellen bis es performant läuft und solange die Software in XE2 entwickeln, was ja auch schon einen Quantensprung zu Delphi2007 wäre.

[Bernhard Geyer]

Zitat von OlliWW:

Ich habe überall im Programm Zeitmessungen, bei diesem Beispiel mit 9000 Rows dauert die Abfrage in D2007 0,5 Sekunden und in XE3 1,5.
Es gibt aber auch Stellen im Programm wo der Unterschied: 5 zu 20 Sekunden ist.

Hat du schon mal bei DevArt im Forum gefragt ob sie ähnliche Erfahrungen haben?

Zitat von OlliWW:

Die Software richtet sich ausschließlich an den deutschsprachigen Raum für eine internationalisierung der Software müssten noch ganz andere Hürden genommen werden

Die (Haupthürte) haben wir 2002 mit D6 genommen. Aber zwischendurch tauchen neue "hürtchen" auf

Zitat von OlliWW:

Die Datenbanken bewegen sich zwischen 50 und 100 GB.

Ok. ist ne richtige DB. Dürfte aber kein Haupthinderungsgrund sein.
Vor allem sollte man bedenken das MS vermutlich bei manche Aktionen eh die varchars nach nvarchars wandelt um relevanten Code nicht doppelt halten zu müssen.

Zitat von OlliWW:

..., sie dafür aber spürbare Performanceeinbußen haben.

Grundsätzlich ist das Stringhandling in XEx besser als in alten Delphi-Versionen - Jedenfalls wenn man wie wir unter D6 mit der Performancekrücke Widestring arbeiten müssen.

Zitat von OlliWW:

Ich bin gerade dabei mir eine XE2 Testumgebung aufzusetzen und werde nun die Performance mit XE2 testen. Sollten die Ergebnisse dort zufrienstellend sein könnte ich mich auch damit anfreunden das Projekt "XE3" solange zurück zu stellen bis es performant läuft und solange die Software in XE2 entwickeln, was ja auch schon einen Quantensprung zu Delphi2007 wäre.

Testumgebungen ist eine gute Idee.