[Gelöst]REPEAT extrem langsam

Hallo alle!

Es ist zum Verzweifeln...
I laufe einen gefilterten Record mit dem REPEAT-Konstrukt durch.
Und ich habe versucht, herauszufinden, warum mein code so langsam ist.
Der Code innerhalb des REPEAT-Konstrukts an sich ist nicht langsam - ein Durchlauf dauert zw. 0 und 31 Millisekunden.
Es sieht so aus:

REPEAT;
// mein Code ->> zw. 0 und 31 Millisekunden
UNTIL myRecordVar.NEXT = 0; // ->> jew. mehr als 10 Millisekunden

zB: Wenn ich die Zeit messe von vor REPEAT bis nach UNTIL, dauert das 971 Millisekunden; wenn ich dagegen the Zeit messe von nach REPEAT bis vor UNTIL und die Zeiten der einzelnen Durchläufe summiere, erhalte ich 124 Millisekunden. Das heißt, dass von den 971 Millisekunden 847 Millisekunden nicht für die Verarbeitung des Codes innerhalb des REPEAT-Konstrukts aufgeht. REPEAT läuft 77 mal durch. Das macht 11 Millisekunden pro Durchlauf.

Was kann REPEAT derart bremsen?!

Vielen Dank schon mal für eure Hilfe!
Gerald

Zuletzt geändert von BadGer am 22. Mai 2009 09:23, insgesamt 1-mal geändert.

Ich rat mal: was für ein find steht da denn vor (-,+,first,set etc)?

Sorry - genau:
Ich habe eine native DB und verwende FIND('-')

Schade, ich hatte auf ein findfirst gehofft

Greift der Code innerhalb der Schleife derart auf dein Recordset zu, dass die Reihenfolge darin geändert wird?

nein, ich verarbeite nur die Feldwerte

Dann gehen mir so langsam die Ideen aus. Ist ein passender Schlüssel gesetzt?

Vielleicht helfen ja ein paar mehr Zeilen Code im Thread, am besten hübsch in CODE-Tags verpackt.

@McClane:
Woher weiß ich, was ein "passender" Schlüssel ist?
Außerdem, wie hängt das mit einem Schlüssel zusammen? Ich gehe mit NEXT ja nur von einem Datensatz zum nächsten, oder?

@FAFL:
Was möchtest du gerne wissen?
Die Zeit für die SETRANGEs ist gleich 0 Millisekunden.
Der Code innerhalb des REPEAT braucht fast keine Zeit.
Mit über 10 Millisekunden pro Durchlauf ist nur die REPEAT-Schleife selbst extrem langsam, bzw. das NEXT.

Mit einem passenden Schlüssel meinte ich einen, der zu deinen SetRanges passt (insofern da welche sind ;), also möglichst einen, der alle eingegrenzten Felder enthält.

Achso, ja - den habe ich so gewählt.

@FAFL:
Was möchtest du gerne wissen?
Die Zeit für die SETRANGEs ist gleich 0 Millisekunden.

Das ist ja auch völlig klar, denn da passiert ja noch garnichts, die Abfrage beginnt ja erst mit dem FIND. Dennoch können die Filter und insbesondere der Schlüssel interessant sein.

Der Code innerhalb des REPEAT braucht fast keine Zeit.
Mit über 10 Millisekunden pro Durchlauf ist nur die REPEAT-Schleife selbst extrem langsam, bzw. das NEXT.

... interessiert mich dann auch erstmal nicht.

Ich habe nur "gewöhnliche" Filter auf Boolean- und Option-Felder.
Außer den hier:
myRecordVar.SETRANGE("Manuf. Date",0D,ToDate);
'ToDate' ist eine Variable die ein Datum enthält.
Kann das wirklich so bremsen?

Auch ist kein Filter auf ein FlowField dabei. Das hätte wohl nach einem CALCFIELDS keine Auswirkung mehr, oder?

Wie sieht´s denn mit der Reihenfolge der SetRanges aus - entsprechen die der Reihenfolge der Felder im gewählten Schlüssel?

Die Reihenfolge hat nicht übereingestimmt.
Allerdings wird alles noch langsamer, wenn die Reihenfolge übereinstimmt eigenartig...

Allerdings wird alles noch langsamer, wenn die Reihenfolge übereinstimmt eigenartig...

Wo man das doch beachten soll

Wie kommst du eigentlich an die Zeitangaben?

Hi!

Wie die Kollegen schon sagten: ein paar Zeilen mehr vom Code wären hilfreich; insbesondere welcher KEY und welche FILTER vor dem Schleifeneinstieg gesetzt sind. Wichtig wäre auch zu wissen, ob/welche Werte der Instanz "MyRecordVar" innerhalb der Schleife geändert werden ...

Gruß,
Jörg

Geändert wird in myRecordVar nichts, es werden nur die Daten verarbeitet.

Code:

myRecordVar.SETCURRENTKEY(Art,"Nr.",Bereich,Belegart,Finished,ReleasedForPurchaseRequest,"Manuf. Date");
myRecordVar.SETRANGE(Bereich,myRecordVar.Bereich::Verkauf);
myRecordVar.SETRANGE(Belegart,myRecordVar.Belegart::Auftrag);
myRecordVar.SETRANGE(Art,myRecordVar.Art::Artikel);
myRecordVar.SETRANGE("Nr.",prcItem."No.");
myRecordVar.SETRANGE(Finished,FALSE);
myRecordVar.SETRANGE(ReleasedForPurchaseRequest,TRUE);
myRecordVar.SETRANGE("Manuf. Date",0D,ToDate);
IF myRecordVar.FIND('-') THEN BEGIN

Wo man das doch beachten soll

Was meinst du damit?

Wie kommst du eigentlich an die Zeitangaben?

Ich habe mir eine einfache Stopuhr gebaut, die ich an einer beliebigen Codestelle starte und an einer anderen stoppe. Die Differenz wird als Duration in eine Tabelle geschrieben.
Völlig "zeitunkritisch". Und sehr praktisch!

Hmmm ... und das wird langsamer, wenn man die Filter in der Reihenfolge setzt, wie die Felder im Key angeordnet sind? Seltsam ...

Wie sieht's denn auf den Festplatten aus? Wie sind Durchsatz und Antwortzeiten? (Mit Windows perfmon messen)
Was für ein Disk-Subsystem läuft da?

Und: wie groß ist der DBMS Cache? Commit Cache aktiv? Wie viele Datensätze werden in der Abfrage abgefiltert?

Wie sieht's denn auf den Festplatten aus? Wie sind Durchsatz und Antwortzeiten? (Mit Windows perfmon messen)
Was für ein Disk-Subsystem läuft da?

Ich habe keine Ahnung...

Und: wie groß ist der DBMS Cache? Commit Cache aktiv? Wie viele Datensätze werden in der Abfrage abgefiltert?

DBMS: 8000 KB
Commit Cache: aktiv

DBMS: 8000 KB
Commit Cache: aktiv

Ist das der DBMS-Cache des Servers? (Datei -> Datenbank -> Information -> Reiter "Datenbank"). Wenn ja, dann ist die Sache sonnenklar.

@FAFL:
Ja
Das heißt?

Zuletzt geändert von BadGer am 19. Mai 2009 15:23, insgesamt 2-mal geändert.

Bin gerade draufgekommen, dass ich im falschen Forum gepostet habe:
Ich arbeite mit Version 4.0 SP3
Tut mir leid!
Kann man das ändern?

Du wunderst dich doch nicht wirklich, dass du mit angezogener Handbremse nicht schnell fahren kannst, oder?

Ok, kann natürlich sein, dass in deiner Tabelle nur 77 Datensätze drin stehen, dann spielt der DBMS-Cache fast keine Rolle, aber wenn da ein paar Tausend Datensätze drin stehen, dann solltest du dich nicht wundern.

Da sind hunderttausende Datensätze drin
Welche Größe sollte der DBMS Chache haben?
Und dass das NEXT so langsam ist, kann damit zusammenhängen?