Office: (Office 2010) Performance verbessern

Hallo. Ich versuche gerade meinen Code etwas zu "überarbeiten" dabei würde ich gerne solche Blöcke etwas performanter gestalten, weiß aber nicht so recht wie ich das angehen soll. Kann mir jemand einen Tipp geben?

Code:

:)

 

Moin,
auf jeden Fall geht es kürzer *wink.gif* ,
Code:

und Textvergleiche sollten durch Fremdschlüssel ersetzt werden, z.B.:
Code:

ergibt dann:
Code:

Mit einem SQL-Select hättest du alle 8 Messungen auf einen Rutsch:
Code:

Was soll denn das überhaupt werden, was ist der Sinn der Übung?
Was machst du später mit den ermittelten Werten?

maike

 

ok erstmal vielen dank ... auch wenn mir noch einiges davon unklar ist
gleich mal zu deiner SQL Anweisung. Wie könnte ich denn die Variable StepNr und TpNr in die SQL Anweisung einbauen?

Was ist der Vorteil wenn ich Textvergleich durch einen Fremdschlüssel ersetze? Nur damit ich es auch verstehe

Und bei einem Fremdschlüssel müsste ich das dann zeilenweise angeben?
also erst Messung = 1
Dann den Code für die erste Messung

Dann Messung = 2
und dann den Code für die zweite Messung ?

 

Genau so, wie du das mit dem Dlookup auch machst. Du verkettest die Feldnamen und die Werte der Kriterien zu einem gültigen SQL-String.

Unmittelbar ist der Vorteil nur gering. Ein numerischer Wert benötigt weniger Speicherplatz und kann daher von der DB-Engine schneller verarbeitet werden. Dies wirkt sich schon mehr aus, wenn die entsprechenden Felder noch indiziert werden.

Der Kernpunkt dieses Hinweises ist IMO jedoch, dass deine Tabelle die Vermutung nahelegt, dass die Daten nicht vollständig Normalisiert sind.

Genau das nicht.
Besser wäre es, wenn du nicht jeden Messpunkt einzeln einliest, sondern die relevanten Messwerte aller Messpunkte mit einem einzigen SQL-Statement in ein Recordset holst und dann jeden Datensatz des Recordsets dem jeweiligen Messpunkt zuordnest. Das ist voraussichtlich knapp 10 mal so schnell, weil du anstelle von 10 Abfragen auf die DB nur noch eine einzige benötigst. Die Verarbeitung der 10 Ergebnisdatensätze ist vom (Rechen-)Zeitaufwand eher zu vernachlässigen.

Die 10 Einzelwerte an die Prozedur zu übergeben, ist auch eher ungünstig für die Wartbarkeit deines VBA-Codes. Besser wäre es, eine geeignete Datenstruktur (Array, Collection, o.ä.) zu übergeben, die alle Werte aufnehmen kann. Auch ein Struct/Type oder eine Klasse wäre für die Datenübergabe an die konkrete Prozedur besser, verschiebt aber das Kernproblem vermutlich nur an eine andere Stelle.

Um konkreter zu werden, wäre es erforderlich, mehr darüber zu wissen, was mit deinen Messwerten passiert, nachdem du sie gelesen hast.

 

Daran hatte ich auch schon gedacht ... das einlesen der Werte in ein Recordset kann ich mir noch vorstellen, die Zuordnung jedoch nicht. Wie geschieht denn dann eine solche Zuordnung? Sorry wenn ich so viel frage :/

An Arrays trau ich mich nicht ran. Hatte erst einmal was damit zu tun und musst mir da auch helfen lassen. Den Weg würde ich daher sehr ungern gehen.

ich werde in einem folgenden Post mal versuchen die weiteren Schritte dazulegen.

 

ich sende damit einen Befehlscode an ein Messgerät:

Code:

 

Michael Zimmermann schreibt:
Performance-Tuning basiert i. d. R. nicht auf „geheimen“ High-Speed-Befehlen, sondern auf Mathematik: Wie viele Bytes werden bewegt, wie viele Schritte sind erforderlich, welche Zusatzkosten entstehen für RAM-Verwaltung, Prozessorbelastung, Plattenzugriffe.

Ein DLookup ist eine vollständige Abfrage, die in VBA verpackt ist und die genau einen Wert holt. So eine einzelne Abfrageausführung und das Rundherum dazu kann schon etwas aufwändig sein. Für mehr als einen Wert ein DLookup-Dauerfeuer einzurichten ist nicht effizient. Du kämst sicher nicht auf den Gedanken und erst recht nicht zur Ausführung, bei 20 benötigten Flaschen Bier für einen Anlass nacheinander einzeln je eine Flasche aus dem Getränkemarkt zu holen (Treppe, Stadt, Ampeln, Markt, Kasse und zurück), sondern wenn Du schon mal da bist, nimmst Du gleich eine Kiste. Diese entspräche dem oben erwähnten Recordset für die Daten.

Zweiter Gedanke: Den ganzen Haufen Messwerte auf einmal zu holen und dann per VBA 8 Suchen für Deine benötigten Werte auszuführen ist ein Weg. SQL kann aber schneller finden als VBA, und SQL kann Massendatenverarbeitung (alles auf einmal). Massendatenverarbeitung ist wiederum meistens schneller als alles einzeln hintereinander zu machen => mit einem Sieb kann man Steinchen von Sand einfacher und schneller trennen als mit zwei spitzen Fingern.
Wenn also Deine Messungsarten selber in einer Tabelle abgelegt sind, könnte man diese Tabelle mit Deiner Datentabelle in einer Abfrage unmittelbar verknüpfen und gezielt nur die benötigten Messwerte ermitteln und per Recordset ausgeben.

Was man dabei bemerkt: Gescheite Verarbeitungsmethoden erfordern auch gescheite Datenstrukturen, das schnelle SQL eben gut strukturierte Tabellen.

 

Ok, vergiss, was ich zur Übergabe an die Prozedur geschrieben habe. Das ist hier nicht relevant.

Die Empfehlung SQL + ein Recordset statt zahlloser Dlookups zur Performanceverbesserung zu verwenden, ist allerdings noch viel effektiver als zuerst gedacht. Du kannst alle Dlookups mit einer einzigen Abfrage ersetzen.

Darüber hinaus solltest du dich auch mal mit For-Next-Schliefen in VBA auseinandersetzen. Ich denke, dein gesposteter Code könnte auf insgesamt weniger als 30 Zeilen reduziert werden.

 

Schön wie du mir das mit dem Bier verdeutlicht hast ... das gefällt mir aus Bayern natürlich besonders gut :-)

Ok das heißt ich löse das in etwa so?:
Code:

 

Wenn Du nur die Datensätze für diese beiden Zustände benötigst, dann ja.
Recordsetschließen nicht vergessen.

500 Jahre Reinheitsgebot muss man ja auch mal würdigen.

 

Du weisst schon, dass das das erste Anti-Drogen-Gesetz in D ist? *cool.gif*

 

Hallo
als ich vor 40 Jahren mit EDV begonnen haben Hatten wir ein anderes Beispiel:
Du musst so schnell als möglich von Bern nach Zürich (ca 100 Km) 10 Bette transportieren.
Was nimmst Du Dein neuen Porsche oder Dein alten LKW *wink.gif*

 

Ganz schlechtes Beispiel: SQL würde ich nicht als alten LKW bezeichnen, und wenn Schweizer ein Auto mal richtig laufen lassen wollen, müssen sie schon rüberkommen auf eine deutsche Autobahn.

 

Hallo
Also nehmen wir Frankfurt Berlin
ich sage nicht das SQL ein alter LKW ist
nur das das Richtige Gefährt (Gefäss) gewählt werden Sollt !
z.b Porsche 2* (1+Letze Fahrt) + 8* 100 km fahren muss
LKW 2* (hin und zurück ) also 2 * 100 km
da spielt es auch keine rolle wo auf der Welt das ist

 

\@ Eberhard

Ruedi hat das sicher anders gemeint ... er würde den Porsche nehmen, die Bretter sind nur 40cm lang und 10cm breit *grins

er hat's schon gerade selbst erklärt, ich will das trotzdem loswerden *wink.gif*