Scope langsam???

[Jan]

Die meisten hier wissen, das ich überzeugter Fan von Scopes bin. Im Moment erlebe ich bei einem Kunden aber eine böse Überraschung.

Ich möchte alle Aufträge eines Kunden zusammentragen. Der Kunde kann mehrfach angelegt sein, das wird vorab geklärt und alle seine Kundennummern in ein Array geschrieben. Das sieht dann in der Scope-Version so aus:

Code: Alles auswählen

auze->(OrdSetFocus("auzeadnr"))
FOR i := 1 TO Len(MEMVAR->gaAdressDubletten)
    auze->(DbSetScope(SCOPE_BOTH, MEMVAR->gaAdressDubletten[i]))
    auze->(DbGoTop())
    DO WHILE .NOT. auze->(EoF())

Ich habe das auf der Suche nach einem Performance-Problem auf Vorschlag (naja, eher Aufforderung) meines Kunden auf klassische Methode umgeschrieben:
auze->(OrdSetFocus("auzeadnr"))

Code: Alles auswählen

FOR i := 1 TO Len(MEMVAR->gaAdressDubletten)
    auze->(DbSeek(MEMVAR->gaAdressDubletten[i], , "auzeadnr"))
    DO WHILE auze->adressnr == MEMVAR->gaAdressDubletten[i] .AND. .NOT. auze->(EoF())

Und diese Version ist ca. 50x schneller! Wie kann das denn sein?

Jan

[Tom]

Hallo, Jan.

Was macht ein DbSeek? Es sucht im Index nach dem ersten passenden Datensatz und positioniert den Satzzeiger dort. Anschließend muss keine Bedingung mehr geprüft werden, denn die Tabelle folgt der Reihenfolge, die der Index vorgibt. Du machst ganz simpel DbSkip() und fragst EoF() ab. Es passiert also im Prinzip nichts weiter als unmittelbare Tabellennavigation.

Ein Scope sucht den ersten passenden Datensatz (das DbGoTop() kannst Du übrigens weglassen - es geschieht implizit) und formuliert eine Bedingung für die Workarea. Mit jeder Navigation wird geprüft, ob die Bedingung erfüllt bleibt. Das geschieht zusätzlich zur Datenbanknavigation - es muss also langsamer sein als der klassische Ansatz. Der ist für die Aufgabe, um die es geht, dann auch tatsächlich der geeignetere. Ein Scope ist gut geeignet, um eine Datensatzmenge einzugrenzen, etwa für One-to-many-Browses, Kreuztabellenanforderungen und ähnliches, aber um einmalig die passenden Datensätze in einer abhängigen Tabelle zu erheben, muss DbSeek() mit einer nachfolgenden DO-WHILE-Schleife schneller sein. Allerdings überrascht mich der Faktor 50. Da scheint mir noch etwas anderes im Busch zu sein.

[Jan]

Hallo Tom,

das DbGoTop() habe ich drin, seit ich mal ganz böse Probleme damit hatte. Ich war immer davon ausgegangen, das ein DbScope() immer "oben" starten würde. War in dem Fall aber nicht. Seitdem baue ich das grundsätzlich ein. Auch wenn ich weiß, daß das eigentlich sinnlos ist, und das es natürlich auch Zeit kostet.

Jan

[Herbert]

Danke Tom, interessante Aussage!

[Tom]

Hallo, Jan.

Das DbGoTop() kann sinnvoll sein, aber eigentlich nur bei Mehrfachrelationen und ähnlichem.

Wie gesagt, der von Dir angegebene Faktor 50 überrascht mich. Wie hast Du das gemessen? Ist die Latenz immer noch so hoch, wenn Du den Code wirklich auf das beschränkst, was die Datenbanknavigation ausmacht? Also so:

Code: Alles auswählen

nTime := Seconds()
db->(DbSetScope(SCOPE_BOTH,xValue))
DO WHILE !db->(Eof())
  db->(DbSkip())
ENDDO
nTime := Seconds()-nTime
? nTime

Und das ganze dann noch einmal mit DbSeek.

Edit: Code korrigiert.

[Werner_Bayern]

Scopes lassen sich im allgemeinen immer in solchen Situationen einsetzen, die eine SEEK/WHILE Schleife erfordern.

Dann ist die Empfehlung in der Hilfe nicht richtig?

Ich denke auch wie Tom, da ist noch was anderes?

[Tom]

Hallo, Werner.

Ein (geringer) Geschwindigkeitsunterschied ist m.E. nachvollziehbar, wobei sich natürlich meiner Kenntnis entzieht, wie das genau umgesetzt ist. Im DO-WHILE-!Eof() ohne Scope passiert ja das gleiche wie in der gleichen Situation mit Scope, nur dass es zusätzlich eben einen Scope gibt. Der muss geprüft werden. Aber der Faktor 50 kann nicht richtig sein. Zumal ja andererseits in der Seek-Schleife jedes Mal geprüft wird, ob das Feld noch der Bedingung genügt.

Da ist noch etwas anderes im Busch.

Ich setze Scopes auf die gleiche Weise ein. Drastische Latenzen sind mir bislang nicht aufgefallen.

[Jan]

hallo Tom,

wie gesagt, ich selber setze Scopes sehr gerne ein. Und hatte bislang nie Performance-Probleme damit.

Hier bei meinem Kunden gibt es aber heftige Probleme. Abläufe, die normalerweise nur 1/2 Sekunde dauern, brauchen manchmal mehr als 3 Minuten! Noch besser: Das Programm wird 2x auf dem gleichen Rechner gestartet. Die eine Instanz ist immer normal schnell die zweite (wenn sie denn anfängt, in genau diesem eng begrenzten Bereich langsam zu sein), ist auf den gleichen Kunden immer langsam. Man kann die gleiche Funktion parallel immer und immer wieder aus dem Menü der jeweiligen Instanzen aufrufen - die schnelle ist immer schnell, die langsame immer langsam.

Und ja, der Unterschied ist wirklich so groß. Ich habe das mit Seconds() gemessen. Und reproduzierbar war die eine Schleife immer 0,53 Sekunden, die andere immer 0,01 Sekunden. Alles andere in der Schleife ist unverändert. Nur die geposteten Zeilen sind verschieden.

Jan

[AUGE_OHR]

Hier bei meinem Kunden gibt es aber heftige Probleme. Abläufe, die normalerweise nur 1/2 Sekunde dauern, brauchen manchmal mehr als 3 Minuten! Noch besser: Das Programm wird 2x auf dem gleichen Rechner gestartet. Die eine Instanz ist immer normal schnell die zweite (wenn sie denn anfängt, in genau diesem eng begrenzten Bereich langsam zu sein), ist auf den gleichen Kunden immer langsam.

Frage : schon mal den Code mit v1.9.335 getestet ?
ich hatte schon mit der v2.0.519 einige Scope Konstruktionen die extrem "langsam" waren aber mit der v1.9.355 normal "schnell" waren.

[Jan]

Jimmy,

das IST 1.9 SL1.

Jan

[UliTs]

Was ist hier draus geworden?

[Jan]

Hallo Uli,

öhm, ja, hmm, äh, ... Keine Ahnung mehr, das ist in meinem Gedächtnis leider nicht mehr existent. Das läuft immer noch auf die Art, die der Kunde gerne hätte, also ohne Scope. Jetzt allerdings inzwischen nicht mehr FOXCDX pur, sondern im ADS. Keine Ahnung ob das jetzt noch relevant wäre.

Jan