SDAC Select unter XE3 sehr langsam

[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.

[OlliWW]

Hallo,

Eine "erfolgs"-Meldung:
Unter XE2 funktionieren die Abfragen mit SDAC in gewohnt-schneller Art und Weise. Es liegt tatsächlich an diesem, noch unerledigtem, Problem von Embarcadero:
http://qc.embarcadero.com/wc/qcmain.aspx?d=111942
Ich denke wir werden erstmal weiter mit XE2 entwickeln, bis XE3 so stabil ist, dass man es produktiv nutzen kann.

Vielen Dank an alle für die Tipps, Hinweise und verdammt schnelle Hilfe (im Devart Forum habe ich zeitgleich gefragt und bis jetzt keine Antwort erhalten).

[Bernhard Geyer]

Zitat von OlliWW:

Unter XE2 funktionieren die Abfragen mit SDAC in gewohnt-schneller Art und Weise. Es liegt tatsächlich an diesem, noch unerledigtem, Problem von Embarcadero:
http://qc.embarcadero.com/wc/qcmain.aspx?d=111942

Komisch. Hätte nicht gedacht das hier die Emba-Implementierung so auf die DevArt-Kompos durchschlägt.

[OlliWW]

Zitat von Bernhard Geyer:

Komisch. Hätte nicht gedacht das hier die Emba-Implementierung so auf die DevArt-Kompos durchschlägt.

In der Tat, es hat mir in der Zwischenzeit aber auch einer vom DevArt Team bestätigt:
http://forums.devart.com/viewtopic.php?f=6&t=26258

[Sir Rufo]

Wieso soll das "komisch" sein?

Das Problem ist in TStringField /TWideStringField und die werden eben halt benutzt und nicht neu implementiert.

Aber auf mich hört ja keiner

[Bernhard Geyer]

Zitat von Sir Rufo:

Wieso soll das "komisch" sein?

Das Problem ist in TStringField /TWideStringField und die werden eben halt benutzt und nicht neu implementiert.

Das diese Felder verwendet werden ist klar. Hatte aber (Aufgrund meiner ADOExpress-Erfahrung) erwartet da an anderer Stelle die Zeit vergeutet wird.

[Bernhard Geyer]

Zitat von OlliWW:

Zitat von Bernhard Geyer:

Komisch. Hätte nicht gedacht das hier die Emba-Implementierung so auf die DevArt-Kompos durchschlägt.

In der Tat, es hat mir in der Zwischenzeit aber auch einer vom DevArt Team bestätigt:
http://forums.devart.com/viewtopic.php?f=6&t=26258

Das ist jetzt die Methode für AnsiString. Aber ähnliches ist auch bei (Unicode)String zu finden.
Müsste man jetzt in der TEncoding-Classe schauen was da so Zeit gefressen wird.