Performance: mein Programm trödelt!

[NicoleWagner]

Hallo User,

ich habe Delphi XE 3, Professional.
Und damit ein kleines Programm geschrieben: ein Formular, ein paar Panels, ein paar schlanke Textdateien als Input. Einige arrays, die mir performant erzeugt und vernichtet erscheinen. Für dieses Programm sollte mein PC einen Wimpernschlag benötigen, es zu starten.
Es braucht jedoch 3-4 Sekunden, bis es sich zeigt.

Wie finde ich die angezogene Handbremse?
Es kann etwa sein, dass ich ein array in einer falschen Schleife zig mal erzeuge. Doch wenn ich es konkret wüsste, würde ich es ändern.
Als letzter Notanker würde ich Zeitmesser in meinen Code setzen. Doch das ist recht viel zu-Fuss-Arbeit.

Wie kann ich das herausfinden?
Gibt es da Tools oder Befehle, die schnell aufgerufen sind?

Danke für Tipps!

[stahli]

3-4 Sekunden kann man vielleicht sogar mit F8 und F7 finden.

Wenn es weiter ins Detail gehen soll, kann ich AQTime empfehlen.
Ich bin aber nicht sicher, ob es da bei XE3 eine kostenfreie abgespeckte Version gab.

Wenn man solche Untersuchungen häufig braucht, lohnt sich auf jeden Fall die Prof-Version.

Ansonsten sind Zeitstempel loggen wohl die einfachste Variante.

[Der schöne Günther]

Es gibt Tools, die nennen sich Profiler. Bis Delphi XE7 (meine ich) war eine Embarcadero-Edition von AQTime dabei, und das kann ich ebenfalls nur empfehlen. Ob das bei XE3 der Fall ist kann ich sagen. Ein bisschen Einarbeitungszeit wird man aufbringen müssen, aber damit kann man wirklich wahre Wunder vollbringen.

Ansonsten ist der Tipp mit dem Debugger und F7-F8 sicher hilfreicher als er sich anhört. Versuch es doch mal, damit findest du innerhalb weniger Sekunden doch schon einmal wo es wohl hängt - Beim Erzeugen der Formulare? Wenn ja, welches? Wenn es einen Verursacher gibt, wo genau?

[WladiD]

Häufig ist ein Virenscanner "schuld".

Versuche dort für die Exe oder den beinhaltenden Ordner eine Ausnahme hinzuzufügen.

[Lemmy]

"etwas" günstiger ist ProDelphi http://www.prodelphi.de/

Wichtig hier: für die Messung wird der entsprechende Code in deine Units aufgenommen - d.h. vorher einchecken - oder Sicherung erstellen!

[Bernhard Geyer]

Zitat:

Zitat von NicoleWagner (Beitrag 1466908)

... Einige arrays, die mir performant erzeugt und vernichtet erscheinen...

Wirklich? Schon mal geschaut wie viel Speicher deine Anwendung beim Start benötigt.
Evtl. hast du ja hier eine "ungünstige" x-GB-Große Arrays die du anlegst und Zeit zum start benötigen.

[DieDolly]

Zitat:

"etwas" günstiger ist ProDelphi http://www.prodelphi.de/

Noch günstiger, sogar kostenlos, geht es entweder wie stahli sagte mit F7 und F8.
Oder aber du setzt in der DPR und im OnCreate der Formulare die du erzeugst mal sporadisch showmessage(''); rein durchnummeriert von 1 bis 10 oder A bis ....
Es dauert nicht lange und du siehst sofort, was Sache ist.

[NicoleWagner]

Danke für alle Antworten!
Ja, jetzt wo Ihr es sagt, AQTime war damals dabei, - doch ich kam damit nicht zurecht. Ich habe es aus meiner VM (die auch schlank sein soll) schon so lange entfernt, dass ich es schon wieder vergaß. Es kann sein, dass AQTime eher für höhere Versionen als die Pro geschrieben wurde und in der Pro zwar dabei war, doch nicht ordentlich läuft.

F7 und F8 geht bei mir eher nicht. Denn meine IDE hat Schluckauf schon seit ihrer Geburt. Delphi XE3 ist keine Glanzleistung von Embarcadero. Zuweilen müllt mir alleine die Programmierhilfe den Speicher so zu, dass ich Delphi mit dem Taskmanager abschießen muss. (Das hat jedoch wenig zu tun mit der schlechten Performance meines Programmes. Das ist fast sicher ein Programmierfehler.) Trotzdem ist F7 und F8 zu ungenau, denn das wäre dann möglicherweise der IDE-Schluckauf statt meines potentiellen Fehlers. Und F7 springt mir in den Maschinenquellcode, auch wenn ich es "einstelle", dass es das nicht tun soll ;-(
Ich arbeite in meiner Verzweiflung ersatzweise mit F4.

Ich werde zähneknirschend tun, was ich damals in Pascal tat: Eine paar globale Zeit-Variable erfinden. In der ersten wird "now" abgespeichert und danach immer wieder die Zeit (now) geholt und abgespeichert nach einem weiteren Programmschritt. "on destroy" werde ich dann subtrahieren und die Differenzen zwischen den Messungen ausgerechnet haben. Mit anderen Worten: ich speichere "now" in den globalen Vars zeit1, zeit2, zeit3,.... und sehe die jeweils vergangene Zeit.

Ein Graus in Zeiten von OOP...

[DieDolly]

Das mit den Zeitvariablen kannst du einfacher mit showmessage's machen. Bei 3 bis 4 Sekunden sieht man auch so, wo es Probleme gibt.

[Hobbycoder]

Wenn man Zeitspannen im Sekundenbereich erfassen möchte, können sich diese auch schnell aus Teilzeiten zusammenaddieren. Ob da ShowMessage wirklich immer geeignet ist, und nicht das Ergebnis zu stark verändert? Immerhin vergeht das schon die eine bis anderen 100ms bis man die weggeklickt hat.

Ich habe das dann immer so gemacht, dass ich mir als erstes eine StringList erzeugt habe, und dort mit mittels GetTickCount einen Zeitstempel und dahinter einen Text hineingeschrieben habe.
Z.B. so

Delphi-Quellcode:

sl.Add(inttostr(GetTickCount) + ': OnCreate - Enter');

am Ende der Procedure so

Delphi-Quellcode:

sl.Add(inttostr(GetTickCount) + ': OnCreate - Leave');

Am Ende das ganze einfach in ein temporär angelegtes TMemo oder als Datei wegschreiben.
Die eine Zeile ist schnell an die eine oder andere Stelle kopiert und angepasst und man kann sie innerhalb der Proceduren strategisch platzieren umd Rechenintensive Abläufe zu optimieren.
Hat mir immer gute Dienste geleistet.

[philipp.hofmann]

Showmessages oder klassisches Logging in ein File, geht auch mit Delphi denkbar einfach, kostet recht wenig Ressourcen und liefert immer Unmengen von Informationen, wenn man mal nicht weiter weiß. Also ich debugge 80% des Codes via Logging, weil es für mich einfach schneller geht. Ich habe dann im Code ein Info- und ein Debug-Logging, so dass in der ausgelieferten Version per Default nur das Info-Logging an ist, man kann es aber zur Laufzeit umstellen (also ein wenig das gute alte Log4J nachempfunden).

Für oftmals durchlaufende Prozeduren erfasse ich nur die Zeit und gebe am Ende des Programms dann die Summen und die Anzahl aus, damit das Logging hier nicht die Performance drückt. Auch dies läuft in einem flexiblen Singleton mit einer Liste von Key/Count/Sum-Werten, also keine globalen Variablen.

[himitsu]

AQTime am Besten als Einzelanwendung benutzen, also sich nach dem Programmstart ans Programm hängen, bzw. die EXE vom AQTime starten lassen.
In der IDE integriert machte es bei uns, und scheinbar auch vielen Anderen, nur Probleme.

[TiGü]

Warum interveniert hier denn keiner?
Ein Debuggen ohne schrittweises Fortschreiten mit F8 und Rein springen in Funktionsaufrufe mit F7 ist doch total sinnlos.
So kann man doch nicht entwickeln!

Da solltest du nochmal Energie reinstecken, ob das Problem nicht eher woanders (Drittanbieter-Tools in der IDE) oder vor dem Gerät sitzt ("Ich weiß nicht richtig, wie man debuggt und möchte das auch nicht lernen").

Mit schrittweisen debuggen hättest du die drei bis vier Sekunden schon lange gefunden.

Das ging auch in XE3!

[NicoleWagner]

hier ist der Quellcode aus der Steinzeit:
Zeit - zeit9 werden verteilt ala:

zeit9:=now;

vor 'end.' steht dann:
Zeit10:=Zeit9 - zeit8;
Zeit10:=Zeit8 - zeit7;
Zeit10:=Zeit7 - zeit6;
Zeit10:=Zeit6 - zeit5;
Zeit10:=Zeit5 - zeit4;
Zeit10:=Zeit4 - zeit3;
Zeit10:=Zeit3 - zeit2;
Zeit10:=Zeit2 - zeit1;
Zeit10:=Zeit1 - zeit;

Da geht man die Werte mit F8 durch und lässt sich jweils Zeit10 anzeigen.
Wo meine Zeit geblieben ist, da bin ich noch nicht sicher. Denn Zeit 10 ist fast immer Null, bis auf eine einzige Differenz mit 2 Millisekunden. Das ist mal ein Kanditat für die Verspätung. Ansonsten werde ich die Zuweisungen noch anders verteilen.

[Lemmy]

Zitat:

Zitat von TiGü (Beitrag 1466960)

Mit schrittweisen debuggen hättest du die drei bis vier Sekunden schon lange gefunden.

unter der Annahme, dass die genau bei einem oder vielleicht zwei Funktionsaufrufe verloren gehen sicher.

Kleine Anekdote:
Nach einem wunderbaren Vormittag vor ca. 12 Jahren brauchte meine Anwendung auf einmal mehrere Minuten, bis diese beendet wurde.
Habe lange gesucht. Selbst die ein, zwei Funktionen geprüft, die ich neu eingebaut habe. Liefen in ein paar ms durch...
Am Ende habe ich meinem Chef die 80€ für ProDel aus den Rippen geleiert, damit dauerte es ne knappe halbe Stunde das Problem zu finden (also Download, Installation, kurz über die Anleitung fliegen und anwenden). Meine tolle Funktion die 10 ms dauert wurde halt ein paar mio mal aufgerufen. Seit dem halte ich mich mit Vermutungen über "was dauert da so lange" gar nicht auf: erst messen, dann machen.

Viel geht sicher mit GetTickCOunt und Co. Bei fehlerhaften Aufrufen wird das dann (je nachdem wie man ausgibt) schon komplizierter.

Nachtrag: ein guter Logger kann hier natürlich auch helfen - Synlog das im Mormot dabei ist finde ich z.B. Klasse, das hat auch einen Viewer dabei, mit dem hätte ich das Problem oben auch gefunden (aber sicherlich mehr Zeit dafür gebraucht, weil du eben jeden Prozedureinsprung selbst mit einem Logaufruf impfen musst...

[Andreas13]

Zitat:

Zitat von NicoleWagner (Beitrag 1466946)

... Trotzdem ist F7 und F8 zu ungenau, denn das wäre dann möglicherweise der IDE-Schluckauf statt meines potentiellen Fehlers. Und F7 springt mir in den Maschinenquellcode, auch wenn ich es "einstelle", dass es das nicht tun soll.

Kann es sein, daß Du Dein Programm nicht im Debug- sondern im Relaese-Modus kompiliert hast?
Gruß, Andreas

[Benmik]

Ich bin schon ein bisschen baff, weil ich dauernd an meinen Routinen (Grafikverarbeitung) herumbastle und schaue, ob ich sie nicht ein bisschen schneller kriege. Ich nehme dazu schlicht und einfach

Delphi-Quellcode:

GetTickCount

, in den seltensten Fällen

Delphi-Quellcode:

QueryPerformanceCounter

, und ich dachte, alle anderen täten das auch.

Meine einfachste Messvorrichtung geht so:

Delphi-Quellcode:

procedure Zeit(var GTC:Cardinal;Anzeigen:Boolean = False);
begin
  If Anzeigen
    then Showmessage('Benötigte Zeit: ' + FormatFloat('0,',GetTickCount - GTC) + ' Millisekunden.   ')
    else GTC := GetTickCount;
end;

procedure MachWas;
var GTC:Cardinal; 
begin
  Zeit(GTC);
  Sleep(100);
  Zeit(GTC,True);
end;

Die aufgebohrte Fassung, mit der ich beliebig viele Verarbeitungen auf einen Schlag erwische, egal, wo sie sich befinden, geht so (habe allerdings erst kürzlich daran herumgebosselt, Bugs sind also möglich):

Delphi-Quellcode:

procedure Zeit(Titel:string;var Txt:string;var GTC:Cardinal;ZeitEnde:Boolean = False;Anzeigen:Boolean = False);
var AnzMsec:Cardinal;
const LZ5 = #32#32#32#32#32;
begin
  // Schluss aller Zeitmessungungen, Anzeige Ergebnis
  If Anzeigen then begin
    AnzMsec := GetTickCount - GTC;
    Txt := Txt + FormatFloat('0,',AnzMsec) + ' msec';
    Showmessage(Txt);
  // Endpunkt der aktuellen Zeitmessung ohne sofortigen Beginn der nächsten Zeitmessung
  end else if ZeitEnde then begin
    AnzMsec := GetTickCount - GTC;
    Txt := Txt + FormatFloat('0,',AnzMsec) + ' msec' + sLineBreak;
  // Endpunkt der aktuellen Zeitmessung mit sofortigem Beginn der nächsten Zeitmessung
  end else if EndsText(LZ5,Txt) then begin
    AnzMsec := GetTickCount - GTC;
    Txt := Txt + FormatFloat('0,',AnzMsec) + ' msec' + sLineBreak;
    Txt := Txt + Titel + ': ' + LZ5;
    GTC := GetTickCount;
  // Beginn der allerersten Zeitmessung oder Aufruf einer neuen Zeitmessung ohne andere Messung unmittelbar davor
  end else if (Txt = '') or EndsText(sLineBreak,Txt) then begin
    Txt := Txt + Titel + ': ' + LZ5;
    GTC := GetTickCount;
  end else begin
    Showmessage('Fehler bei der Anordnung der Aufrufe.');
  end;
end;

procedure TForm1.FormCreate(Sender: TObject);
var GTC:Cardinal; Txt:string;
begin
  Zeit('procedure Zeitfresser1',Txt,GTC);
  Sleep(100);
  Zeit('procedure Zeitfresser2',Txt,GTC);
  Sleep(200);
  Zeit('',Txt,GTC,True);
  // Andere Verarbeitungen
  Zeit('procedure Zeitfresser3',Txt,GTC);
  Sleep(300);
  Zeit('',Txt,GTC,False,True);
  Application.Terminate;
end;

Während der Entwicklungszeit (also ein paar Jahre lang...) benutze ich globale Variablen für GTC und Txt, damit ich sie nicht immer deklarieren muss.

[himitsu]

DateTime/String (vor allem für längere Logs), GetTickCount und es git auch eine neuere Stopuhrklasse, deren Name ich immer vergesse.

Zitat:

#10#13

Falsch, denn für viele Programme/Codes sind #10#13 zwei Zeilenumgrüche (#10 + #13), anstatt Einem (#13#10).
#10 (Linux/Unix), #13 (Apple) oder #13#10 (Windows)
(wobei Apple inzwischen von #13 zu #10 gewechselt ist, aber z.B. das aktuelle RichEdit im Windows nutzt eigenartiger Weise #13)

[Benmik]

Manchmal geht #10#13, manchmal #10, manchmal #13, ich probiere es einfach aus. #9 geht in Showmessage leider nicht, daher meine Konstruktion mit Leerzeichen.
Vielleicht noch hier die Version mit

Delphi-Quellcode:

QueryPerformanceCounter

:

Delphi-Quellcode:

function  HLStoppUhr(Start:Boolean;var Zeitwert:Int64;MSek:Boolean = False;Meldung:Boolean = True):Extended;
var Frequenz,EndWert:Int64;
begin
  If Start then begin
    QueryPerformanceCounter(Zeitwert);
    Result := 0;
  end else begin
    QueryPerformanceFrequency(Frequenz);
    QueryPerformanceCounter(EndWert);
    Result := (EndWert - Zeitwert) * (1 / Frequenz);
    If MSek
      then Result := Result * 1000;
    If Meldung then begin
      If MSek
        then Showmessage('Benötigte Zeit: ' + MitTPkt(Result) + ' Millisekunden     ')
        else Showmessage('Benötigte Zeit: ' + MitTPkt(Result) + ' Sekunden     ');
    end;
  end;
end;

[Sherlock]

TStopwatch ist eine ganz Super Sache.
Und auf jeden Fall (ich lasse mich da auf keine Diskussionen rund um Sonderfälle ein) immer #13#10.

Sherlock

[Benmik]

Zitat:

Zitat von Sherlock (Beitrag 1466976)

Und auf jeden Fall ... immer #13#10.

Mache ich auch, aber neulich ging #10#13 nicht (hab vergessen wo).

TStopwatch ist bestimmt toll, aber bin zu träge, um mich umzugewöhnen, und man muss auch immer System.Diagnostics in uses haben. Mit der globalen Variablen setze ich meine Funktion ohne jeden Aufwand.

PS: Und man kann die Namen der interessierenden Prozesse nicht angeben.

[Delphi.Narium]

Seit Schreibmaschinen bzw. Fernschreiberzeiten (und beim Computer seit DOS-Zeiten) ist es carriage return line feed ->

Delphi-Quellcode:

CR LF

->

Delphi-Quellcode:

0x0D 0x0A

->

Delphi-Quellcode:

#13#10

in Delphi definiert als

Delphi-Quellcode:

unit System; 
...
const
  sLineBreak = {$IFDEF LINUX} #10 {$ENDIF} {$IFDEF MSWINDOWS} #13#10 {$ENDIF};
...

Nimmt man einfach diese Konstante, dann hat man automatisch das Richtige, wenn man mal nicht für Windows, sondern für Linux kompiliert. Und ein "manchmal geht's, manchmal nicht, ich weiß nicht mehr wo ...', gibt es dann nicht mehr ;-)

Zitat:

Zitat von Benmik (Beitrag 1466978)

Zitat:

Zitat von Sherlock (Beitrag 1466976)

Und auf jeden Fall ... immer #13#10.

Mache ich auch, aber neulich ging #10#13 nicht (hab vergessen wo).

@Benmik

#10#13 ist ja auch falsch, dass muss nicht gehen.

Es heißt #13#10.
Also zwei Werte, absteigend sortiert und nicht aufsteigend ;-)

[DasWolf]

Zitat:

Zitat von Benmik (Beitrag 1466978)

und man muss auch immer System.Diagnostics in uses haben. Mit der globalen Variablen setze ich meine Funktion ohne jeden Aufwand.

Das ist jetzt nicht wirklich Dein Ernst, oder? Wo holst Du Dir Deine Funktion denn her?

[himitsu]

Aus einer großen eigenen Master-Unit, wo ALLES eingebaut ist, was man braucht, und die immer und überall eingefügt wird. :zwinker:


Jetzt, wo die Codevervollständigung nun endlich auch bei Units mit Namespace Punkten funktioniert, hab ich da hoffentlich nun auch weniger Probleme mit solchen Unitnamen.

[Benmik]

Zitat:

Zitat von DasWolf (Beitrag 1466986)

Wo holst Du Dir Deine Funktion denn her?

Ich habe eine Unit

Delphi-Quellcode:

ModulAllgemein

, in der alle meine Fundstücke der letzten 200 Jahre stehen und die grundsätzlich in alles eingebunden wird.

@Himitsu: Genau so isses!

... und die natürlich mittlerweile auch große Anteile von Friedhof, Altersheim und Museum hat...

[Benmik]

Zitat:

Zitat von Delphi.Narium (Beitrag 1466983)

#10#13 ist ja auch falsch, dass muss nicht gehen. Es heißt #13#10.

Ja, genau, und neulich ging es nur andersrum... Egal, sLineBreak habe ich schon 10 x vergessen, jetzt versuche ich ein 11. Mal...

[Benmik]

... und übrigens eine endgeile Evaluation meines Codevorschlags...

[himitsu]

Jupp, als Addon .. die erste Zeile was ich so zum Messen nehme.



Hier nehm ich meistens nur #10 weil faul (so lange es nur im Programm bleibt) ... bei Dateien #13#10 (wenn nur für Windows), bzw. sLineBreak.


Ich weiß, 13 ist die Enter-Taste, welche zum Abschluß der Zeile Eingabe benutzt wird, aber [B]historisch[/S] syntaktisch war #13 als Zeilenumbruch schon immer ein bissl falsch.

#13 CR Carriage Return = Wagenrücklauf, als Schlitten nach links
#10 LF Line Feed = Zeilenvorschub = Blatt nach oben (Zeile runter)

Schreibmaschine: Man schiebt den Wagen nach links und dabei wird eine Zeile vorgeschoben. (erst linkst und dadurch dann/auch recht)


In einigen CSV- und alten Excel-Spezifikationen sind #13 und #10 sogar unterschiedliche Dinge (Datensatzwechsel oder Zeilenumbruch in einem Feld)

[TiGü]

Ihr kommt langsam vom eigentlichen Thema ab...:warn:

[TSchnuckenbock]

Bei meinem XE5 war dieses "CodeSite Logging" dabei.

Zusammen mit "now" (?) irgendwann am Anfang und dann weiteren Stellen im Ablauf lasse ich mir die Zeitwerte (Differenzen) via Codesite ausspucken. So habe ich bisher alle Bremsen gefunden.

Das müßte auch mit 'ner eigenen Text-Datei fürs Logging gehen....so mit Formatstrings, in denen die Aufrufstelle und die Zeitdifferenz drinsteckt.

[himitsu]

Die Lizenz für's kleine CodeSite Express ist immernoch mit dabei, wenn ich mich nicht täusche. (kann via GetIt installiert werden)

[DieDolly]

Zitat:

Bei meinem XE5 war dieses "CodeSite Logging" dabei.

Zusammen mit "now" (?) irgendwann am Anfang und dann weiteren Stellen im Ablauf lasse ich mir die Zeitwerte (Differenzen) via Codesite ausspucken. So habe ich bisher alle Bremsen gefunden.

Braucht man für sowas wirklich CodeSite? NicoleWagner hat schon vor einigen Posts bewiesen, das es auch ganz anders geht.

[jaenicke]

Irgendwie fehlt hier noch die einfachste Variante... das passiert doch auch auf dem Entwicklungs-PC:
Einfach starten und in den 3-4 Sekunden Wartezeit auf Pause drücken und dann schauen wo man dort gerade ist.

Bei so langen Verzögerungen klappt das mit ein paar Versuchen normalerweise sehr gut.

[TurboMagic]

Zitat:

Zitat von himitsu (Beitrag 1466973)

DateTime/String (vor allem für längere Logs), GetTickCount und es git auch eine neuere Stopuhrklasse, deren Name ich immer vergesse.

TStopwatch aus System.Diagnostics.
Und für's Logging ist seit vielen Versionen CodeSite Lite dabei.
Funktioniert unter Windows ganz gut.

[NicoleWagner]

In meinem Fall hilft das sehr wahrscheinlich nicht, das in-den-Code-springen. Ich habe mittlerweile ein paar "verdächtige" begin / end gefunden.
Heute bin ich schon zu müde, doch ich habe den Eindruck, dass ich irgendeine Schleife zu groß gezogen habe.

Also statt
for i:1 to 1000 do begin
for j:=1 to 100 do begin end
mach-was
begin
und-dann-noch-ein-Methodenaufruf-in-Schleife
end
end
end?!

Wäre das mach-was-end irgendwohin verrutscht beim Debuggen und es wären dann 100.000 Durchläufe mehr als nötig...
Dass da oben "was" nicht stimmt, sieht jeder auf den ersten Blick. Das richtige end zu löschen, das braucht einen zweiten Blick.

[TurboMagic]

Zitat:

Zitat von Sherlock (Beitrag 1466976)

TStopwatch ist eine ganz Super Sache.
Und auf jeden Fall (ich lasse mich da auf keine Diskussionen rund um Sonderfälle ein) immer #13#10.

Sherlock

In Unit System gibt's die schöne Konstante sLineBreak.Die passt auf jeder Plattform ;-)

[DieDolly]

Delphi-Quellcode:

for i:1 to 1000 do begin
for j:=1 to 100 do begin end
mach-was
begin
und-dann-noch-ein-Methodenaufruf-in-Schleife
end
end
end?!

Zitat:

Wäre das mach-was-end irgendwohin verrutscht beim Debuggen und es wären dann 100.000 Durchläufe mehr als nötig...
Dass da oben "was" nicht stimmt, sieht jeder auf den ersten Blick. Das richtige end zu löschen, das braucht einen zweiten Blick.

Das da oben sieht richtig formatiert so aus

Delphi-Quellcode:

 for i: 1 to 1000 do
  begin
   for j := 1 to 100 do
    begin
    end
    // mach-was
    begin
     // und-dann-noch-ein-Methodenaufruf-in-Schleife
    end
  end
end ?!

Im Prinzip ist da alles falsch. Code-formatierung kann einem solche Probleme ersparen.

Richtig vielleicht so? Ich weiß ja nicht, wp du i und j verwendest

Delphi-Quellcode:

for i := 1 to 1000 do
  begin
   for j := 1 to 100 do
    begin
     // mach-was

     // und-dann-noch-ein-Methodenaufruf-in-Schleife
    end
  end;

Ab und zu STRG+D

[NicoleWagner]

...dass das "richtig formatiert" so aussieht, wissen hier wohl viele, auch ich.
Nur war mir die Spielerei in html zu mühsam.
Dass zu sagen, ist nicht der Grund, warum ich poste.
Sondern ich poste eine Erfolgsmeldung: Ich hab's!

Es war ein "begin-end" zu wenig.
Jenes, das schlank und rank über 2 Zeilen hätte laufen sollen, ging mir in eine riesige Schleife.

Wie passiert so etwas?
Man folgt der Embacadero Richtlinie nicht, jede einzelne Zeile in begin - end einzuschließen, weil das sooo viele Codezeilen macht.
Man schreibt also:
If.... then... ;
Dann - fällt einem noch etwas ein.

Richtig wäre jetzt natürlich gewesen:

if .... then
begin
1.....;
2.....;
end;

Man schrieb aber zu später Stunde:
if then
1....;
2....;

Autsch.
Dieser 2. Befehl läuft dann durch die ganze Ober-Schleife.

Meine Anwendung startet jetzt wieder im Wimpernschlag statt in einigen Sekunden.

PS: Ich schreibe auch " s:= ' ' + #10#13 + ' '; "
Zuweilen geht das nicht und dann fand ich (glaublich sogar hier) einen Trick: Man legt ein "Label" dorthin, wo es nicht klappt und schreibt nicht auf den schlechten Untergrund, sondern aufs Label.

und PPS:
Die Zeitmessung mit "now"-Zuweisung fand die auslösende Stelle NICHT. Da mag die Code-Optimierung daran schuld sein.

[Moombas]

Zitat:

Zitat von NicoleWagner (Beitrag 1467041)

Man folgt der Embacadero Richtlinie nicht, jede einzelne Zeile in begin - end einzuschließen, weil das sooo viele Codezeilen macht.
Man schreibt also:
If.... then... ;
Dann - fällt einem noch etwas ein.

Richtig wäre jetzt natürlich gewesen:

if .... then
begin
1.....;
2.....;
end;

Deswegen habe ich mir angewöhnt, das generell zu machen, damit so etwas nicht passieren kann.
Man muss nicht mal etwas vergessen, sondern es kann eine nachträgliche Ergänzung sein, die mehr erfordert.

[TurboMagic]

Zitat:

Zitat von NicoleWagner (Beitrag 1467041)

Sondern ich poste eine Erfolgsmeldung: Ich hab's!
Meine Anwendung startet jetzt wieder im Wimpernschlag statt in einigen Sekunden.

PS: Ich schreibe auch " s:= ' ' + #10#13 + ' '; "

Super, dass du dein Problem lösen konntest.

Hier noch ein Tipp zum #10#10: es gibt da in System.pas, was ja bekanntlichermaßen immer implizit eingebunden ist,
die schöne Konstante sLineBreak. Diese enthält unter Windows genau das: #13#10 und auf den anderen Plattformen
das jeweils dort standardmäßig benutzte. Nutzung der Konstante macht also den Code ein wenig mehr Multi-Plattform
kompatibel.