Ado Performance steigern

[Dejan Vu]

Zitat von EgonHugeist:

Ich habe die Anzahl der Records auch mal auf 100.000 erhöht, doch der rechnerische Durchschitt bleibt so ziehmlich der Gleiche.

Was ist daran ? Ob ich 1000x messe oder 100.000x ist für den Durchschnitt ziemlich egal. Ob ich nun 10km oder 1000km weit mit 50km/h fahre, ist egal. Es bleiben 50km/h.

Blöde Frage (zu faul zum Blättern): Nehmen wir an, Zeos wäre lahm. Wie sieht es mit reinem ADO aus?

[EgonHugeist]

Dekile, Ja ist ne blöde Frage. Sei mal so gut und schau mal den Eingangs-Thread an.
Diese Tests umgehen ja schon mal alle TDataSet-Performance Verlußte. Somit "reines ADO" Oder eine Automarke deiner Wahl.

Goggle doch mal ein wenig und du wirst schnell festellen, ADO oder "reines ADO" setzt auf OleDB COM Objekten auf. Ist aber quasie eine Zwischen-Schicht, wie Sir Rufo es anmerkte. ADO macht alles schön einfach für den End-user. Persönlich finde ich die Idee, eine Zwischenschicht mit einer weiteren TDataSet-Zwischenschicht zu koppeln etwa wie eine Reise um Deutschland um ins Nachbardorf zu fahren (du wirst es verstehen Bin mir sicher)...

Ok lasse mich darauf ein: Zeos wäre angenommen langsam.
Nun nehmen wir eine Klasse mit diversen abstacten Proceduren um Daten zu senden und wieder zu holen.
Schreibe zwei Descendants, welche overrides zur Verfügung stellen, um dieses eben mit ADO oder mit OleDB zu machen.
Für die ADO-Klasse wirst du, sagen wir, 1.000 Zeilen brauchen, um das Gröbste abzudecken.
Für OleDB sind es wohl eher 10.000 oder mehr.

Rahmen-Bedingungen, wie du die Daten reinschaufelst und am Ende wieder raus bekommst sind die Gleichen, da du nur die Objekt/Klassen zur Verfügung hast, welche vom jeweiligen Provider unterstützt werden. Hupt da was? Könnten wir zum Thema zurück fahren?

[Dejan Vu]

Zitat von EgonHugeist:

Dekile, Ja ist ne blöde Frage...Hupt da was? Könnten wir zum Thema zurück fahren?

Wer ist Dekile, danke für die Blumen, es hupt nichts, mir egal.

Es ist Dein Problem, nicht meins, also wieso erwartest Du von *mir*, zu googeln, zu blättern, zu programmieren oder zu hupen. Piept da was bei Dir? Du willst, das wir dir helfen, vergiss das nicht.

Noch ein Tipp (falls es Deine Attitude zulässt): Fasse deine Ergebnisse doch zu einer Tabelle zusammen. Das ist besser lesbar. Und übersichtlicher. Grenze das Problem ein. Geht es Dir um die Batch-Performance oder um eine Erklärung des Overheads?

Viel Erfolg.

Ein Tipp: Schau Dir mal die SQL-Statements an, die die einzelnen Provider erzeugen.

[jobo]

Zitat von Dejan Vu:

Ob ich nun 10km oder 1000km weit mit 50km/h fahre, ist egal. Es bleiben 50km/h.

Ich halte eine Varianz der Menge für sehr sinnvoll. Je kleiner die Stichprobe, desto mehr Effekte können das Ergebnis verfälschen. Je größer die Menge, desto "stabiler" sollte der Durchschnitt werden.
Dein Satz oben zum 50 km/h Durchschnitt ist für sich genommen sinnfrei und trifft nebenbei die Messsituation nicht.

[EgonHugeist]

Zitat von Dejan Vu:

Zitat von EgonHugeist:

Dekile, Ja ist ne blöde Frage...Hupt da was? Könnten wir zum Thema zurück fahren?

Wer ist Dekile, danke für die Blumen, es hupt nichts, mir egal.

Es ist Dein Problem, nicht meins, also wieso erwartest Du von *mir*, zu googeln, zu blättern, zu programmieren oder zu hupen. Piept da was bei Dir? Du willst, das wir dir helfen, vergiss das nicht.

Noch ein Tipp (falls es Deine Attitude zulässt): Fasse deine Ergebnisse doch zu einer Tabelle zusammen. Das ist besser lesbar. Und übersichtlicher. Grenze das Problem ein. Geht es Dir um die Batch-Performance oder um eine Erklärung des Overheads?

Viel Erfolg.

Ein Tipp: Schau Dir mal die SQL-Statements an, die die einzelnen Provider erzeugen.

"Dekile" ist soweit mir bekannt die serbo-kroatische Verkleinerung von Dejan und bezogen auf dein "Ramba-Zamba"-Bild.

Dejan, ich schätze dich sehr in diesem Forum. Du hast eine gewisse Beharrlichkeit und kannst mit Lösungsansetzen tatsächlich weiter helfen. Auffällig ist deine sarkastische Art, deren zu Folge, ich der Meinung gewesen bin du kannst mit 'nem Echo umgehen. Permanente "Auto-Vergleiche" helfen mir halt nicht weiter und sind ab einem gewissen Punkt nervig. Wollte dir mit meiner minimal sarkastischen "Light" Version nicht auf die Füße treten.

Als ehemaliger Ringer, lernte ich einstecken und austeilen, doch es geziehmt sich auch folgendes: Entschuldige, Dejan. Bleiben wir doch einfach mal beim Thema und sperren die Garage zu ? Handshake!?

Sicher ist es "ein" Problem, doch eigentlich nicht meines. Ich mache das just for fun. Zeos ist ein Hobby-Code für mich.

Die beigefügten Ergebnisse sind "copy & paste" vom Synopse Test. Drei Blöcke miteinander zu Vergleichen sollte auch so noch recht lesbar sein.
Leslicher ist das dann hier
Doch wie voran bemerkt, fehlt da MSSQL in der Liste...

Overhead? Eingrenzen? Sind die Ergebnisse nicht selbsterklärend?

Das Anschauen der stmt... Weiß nicht, ob ich dir folgen kann. Der Server ist immer der Gleiche. Nur die Art des Zugriffs ist geändert. Somit würde ich davon ausgehen, das sich die Provider mit dem Stmt auch gleich Verhalten sollten, oder lieg ich falsch? Welches Szenario wäre denkbar? Ist keine Jet-Engine, welche die selects zerlegt und das holen der Daten improvisiert..

@jobo
Jup! Um Performance-"Wellen" zu deckeln habe ich das einfach mal gemacht. Das weiteren wäre es möglich das ADO z.B. im Hintergrund eine gewisse Datenmenge vorbereitet, welche dann schnellst möglich dem "consumer" zur Verfügung gestellt wird(Sonderbar, auf welche Theorien man kommt...). Aber eben erst nach Vorbereitung. Somit war das Erhöhen der Mess-Daten grundsätzlich relevant führ mich.

Michael