Programmentwicklung, Laufzeit wird zu lange ...

[bernhard_LA]

Ich habe aktuell ein Entwicklungsprojekt bei dem ich 2 Stunden warten muss vom ersten "START Programm" bis zum "Buttonklick" an dem eine Codeänderung vorgenommen haben.
Um die Weiterentwicklung effizient zu gestalten habe ich verschiedene Testdaten mit denen ich die 2 Stunden Wartezeit auf 5 min. reduziere. Allerdings kann ich hier nur bedingt die Änderungen beurteilen.

Wie kann ich hier effizient weiterentwickeln ???

[Mikkey]

Den Status des Systems kurz vor dem entscheidenden Punkt "einfrieren" (abspeichern)?

Für den Test müsste dann der Status jeweils abgerufen werden, so dass das System ab dem Punkt wiederholt weiterlaufen kann.

Je nach Komplexität kann so etwas natürlich beliebig aufwendig werden...

[jaenicke]

Was ist denn der Grund für die Wartezeit? Aufwendige Berechnungen?

Ohne zumindest in groben Zügen zu wissen was da abläuft, vor allem um welche Datenmengen es geht, was mit den Daten vor dem Buttonklick passieren muss, usw. kann dir niemand einen gezielten Rat geben.

Aber das ist dir ja sicher auch selbst klar. Und für detailliertere Vorschläge fehlen auch detailliertere Informationen. Wenn du öffentlich nicht mehr Details schreiben möchtest, kannst du mir auch gerne per PN etwas schreiben.

Meine Idee wäre, wenn das bei deinem Projekt machbar ist, das was bei dem Buttonklick passiert in eine DLL auszulagern. Die könntest du dann zum Debuggen einfach mit LoadLibrary auf Anforderung mit einem Button laden, dich mit dem Debugger verbinden, debuggen und dann die Verbindung wieder trennen und die DLL wieder entladen. Dann kannst du die wieder ändern und das ganze von vorne machen.
Du darfst nur nie das Programm aus Delphi heraus hart stoppen.

[bernhard_LA]

Über die Funktion kann ich leider keine Angaben machen, Danke für die Angebote.
( die Wartezeit ist absolut im Bereich der Erwartungen, die Probleme sind in der Komplexität N*N und wir planen noch größere N als diese 2 h )


DLL : hatte ich auch auf meinem Lösungsradar -> kann ich von einem beliebigen Programm auf eine DLL die von einem ersten Programm gestartet wurde incl. der berechneten Daten zugreifen ???


TCP/IP : Entwicklung einer C/S Funktionalität , ich wollte die Lösung einfacher gestalten

SHARED MEMORY : gibt es so etwas noch ????

[sx2008]

Zitat von bernhard_LA:

SHARED MEMORY : gibt es so etwas noch ????

Klar aber man sollte es meiden wie der Vampir den Knoblauch
Aktuell ist Functional Programming angesagt um Code möglich nebenwirkungsfrei in mehreren Threads laufen zu lassen.

Ich halte DLLs für keine gute Idee um an der Laufzeit irgendetwas zu verbessern.
Im Gegenteil würde das Splitten von Code in DLL(s) und Anwendung die Entwicklung nur noch mehr verlangsamen.

[Nersgatt]

Ich würde versuchen, den Code so zu bauen, dass ich so viele Tests wie möglich über Unittests abdecken kann. Und so die 2-Stunden-Tests auf ein Minimum reduzieren.

[jaenicke]

Zitat von bernhard_LA:

DLL : hatte ich auch auf meinem Lösungsradar -> kann ich von einem beliebigen Programm auf eine DLL die von einem ersten Programm gestartet wurde incl. der berechneten Daten zugreifen ???

Nein, ich meinte das umgekehrt. Dein Programm läuft dauerhaft und hat die Daten. Dann lädt es auf Anforderung die DLL mit den von dir zu debuggenden bzw. optimierenden Funktionen, du verbindest dich aus Delphi heraus mit dem Debugger (wenn du debuggen willst, sonst reicht ja laden der DLL) und startest die Funktion.

Voraussetzung ist natürlich, dass du verhältnismäßig einfach an die Daten herankommst, die du dazu brauchst, sei es per Speicherbereich, Interface oder Callback-Funktion.

Und wenn du die DLL danach wieder entlädst, kannst du sie ändern und danach wieder laden und testen.

Zitat von bernhard_LA:

SHARED MEMORY : gibt es so etwas noch ????

Als MMF würde ich das wenn umsetzen. Das klappt gut und du kannst von mehreren Prozessen darauf zugreifen.

Zitat von sx2008:

Ich halte DLLs für keine gute Idee um an der Laufzeit irgendetwas zu verbessern.
Im Gegenteil würde das Splitten von Code in DLL(s) und Anwendung die Entwicklung nur noch mehr verlangsamen.

Darum ging es auch nicht. Es ging mir rein um eine Möglichkeit ohne die Startzeit zu debuggen.

[grl]

Ich habe in einer meiner Applikationen ein ähnliches Problem: Zuerst werden Daten von einem Gerät aufgezeichnet und dann wird dran rumgerechnet.

Ich habe mir ins Programm eine Möglichkeit eingebaut, den Datenspeicher wegzuschreiben und wieder zu laden - so kann ich eine einmal gemachte Aufzeichnung, an der auch schon Teile berechnet sind wieder laden und das Programm dann daran Weiterarbeiten lassen.

Das Ganze lässt sich via $IFDEF ein- und ausschalten, damit im Echtbetrieb nix passieren kann...


Gruß
GRL

[jaenicke]

Zitat von grl:

Das Ganze lässt sich via $IFDEF ein- und ausschalten, damit im Echtbetrieb nix passieren kann...

So etwas nutze ich auch. Damit solcher Code nie durch einen Unfall im Livebetrieb läuft, frage ich zusätzlich eine Umgebungsvariable ab, die auf dem Entwicklungs-PC gesetzt ist.

[bernhard_LA]

das Thema "Dateien nach der Berechnung irgendwo und irgendwie" zwischen zu lagern wäre eine Lösung nur leider sehr statisch ...


Ich bin am experimentieren mit dem Knoblauch