Performance verbessern

[ramses]

Hallo zusammen

kennt jemand Tricks um die Performance (Ausgeführte Befehle / Sek.) eines XBase++ Programms zu verbessern?

Es geht dabei um Umfangreiche Berechnungen. Alle Daten sind bereits in Array's und Variablen geladen.

[Marcus Herz]

Meist ist ja das Einlesen der Engpass.
Was für Berechnungen sind denn das im Speicher?

[ramses]

Material-Kontrolle und Zuschnittoptimierung

[Marcus Herz]

Ich dachte eher an welche Rechenoperationen.
Zuschnittoptimierung klingt nach Flächen Berechnungen.
Oder sind es mehr Varianten, also verschiedene Array Elemente miteinander vergleichen?

[Tom]

Ich wüsste auch nicht, was man, von allgemeinen Performancetipps abgesehen, vorschlagen sollte. LOCALs verwenden. Zu viele Funktionen (UDFs) vermeiden (Steffen hat mal gesagt, Funktionen würden Overhead generieren, den man gegen die Eleganz einer gut aufgeteilten Anwendung abwägen sollte). INLINE-Methoden in Klassen ab einer gewissen Größe (+/- 20 Zeilen) meiden. Codeblöcke und Makros meiden. Aber, wie gesagt, nur zur Performanceoptimierung, nicht allgemein. Ich kenne Performanceprobleme vor allem im GUI- und Datenkontext. Bei Berechnungen ist das neu. Aber Schnittoptimierungen sind auch extrem komplex. In Roger Donnays eXpress++-Forum (das allen Xbase++-Nutzern offensteht) gibt es einen russischen Professor namens Eugene Lutsenko, der macht vor allem im mathematischen Bereich Irrsinnssachen mit Xbase++-Anwendungen. Vielleicht fragst Du den mal (http://bb.donnay-software.com/Donnay/index.php).

[Manfred]

was ist denn die Eleganz einer gut aufgeteilten Anwendung?

[Tom]

@Manfred: Wenn ich z.B. eine komplexe Auswertung baue, dann kann ich darin Schleifen und Iterationen usw. miteinander verschachteln, und am Ende der Auswertung steht ihr Ergebnis. Ich kann diese Funktion dann aber nur zu diesem Zweck nutzen. Sich ähnelnde oder sich wiederholende Elemente darin könnte ich aber auch auslagern, als Funktionen oder Methoden. Dadurch wird der Code eleganter und leichter lesbar. Wenn sich die ausgelagerten Funktionalitäten jedoch nirgendwo anders verwenden lassen, habe ich u.U. Overhead erzeugt, der mich bremst.

Wenn Du für L&L nur eine Druckroutine hast, die auch nur Tabellen publiziert, dann kannst Du den ja nur einmal verwendeten Code von "DefineData" (zumindest in der Variante, die Arrays entgegennimmt) auch aus der Funktion holen und direkt in die Druckroutine stecken. Das ist zwar weniger elegant, aber möglicherweise marginal performanter.

[Jan]

Carlo,

wenn Du im Array nach Sätzen suchst, kostet das jedes Mal Zeit. Natürlich nicht wirklich viel. Aber wenn das oft gemacht hat dann läppert sich das halt. Das geht schneller wenn man direkt den Satz anspringen kann. Weil man den bereits kennt.

Ich mach sowas ja sehr gerne mit DataObjects. Da habe ich die Möglichkeit, DataObjects als Array-Elemente einzubauen. Da kann ich auch ein AScan() drauf machen. Es geht aber ganz wesentlich schneller wenn ich die DataObjects in ein anderes DataObject stecke. Und dort die MemVars pasende Namen haben, die ich direkt anspringen kann. Wie z. B. die Kundennummer. Ich spare mir dann das AScan() auf die Adressnummer-MemVar der DataObjects im Array, weil ich das direkt ansprechen kann per oDo:[adressnr]:name. Ich habe keine Ahnung ob sowas bei Dir passen würde, das sall nur ein Beispiel sein.

Jan

[Jan]

Tom,

das ist interessant. Mir war nicht bewußt das ausgelagerte Funktionen Zeit kosten. Ich mach das ganz gerne, wenn der Code einer Funktion ansonsten zu lang und unübersichtlich wird. Dann schmeiß ich einfach ganze Schleifen raus in eigene Funktionen. Die dann aber oftmals nur von dieser einen Stelle aus aufgerufen werden.

Weißt Du wie groß der Zeitverlust durch solche Auslagerungen ist?

Jan

[Tom]

Hallo, Jan.

Nein, ich erinnere mich nur an Steffens Aussage von Anno Zopf, dass Funktionen immer auch Overhead mit sich bringen, der bremst*. Ob das in einer normalen Anwendung überhaupt messbar ist, weiß ich nicht. Aber wenn Du eine Million Male irgendwas iterierst, wird es möglicherweise so sein. Das kann man ja ausprobieren.

*Ich erinnere mich allerdings auch an Steffens Aussage von einem der ersten XUG-Treffen, dass die Umstellung einer Anwendung von OEM auf ANSI intern (also über SET CHARSET) einen Performancegewinn in der GUI von bis zu 15 Prozent bringen würde, weil ja für die Captions von XbParts dann nicht mehr von einer Zeichentabelle in die andere konvertiert werden müsste - und umgekehrt. Als ich das dann wenig später tatsächlich gemacht habe, weil ich den Code tatsächlich schon längst nicht mehr für Clipperzeug gebraucht habe, war ich enttäuscht, denn es gab überhaupt keinen messbaren Unterschied. Aber das ist schon ein paar Jährchen her.

[Herbert]

Der Code und dessen Güte ist das Eine, das Andere sind die Verbindungen vom Speicherort zur Berechnung und wieder zurück. Also: Wie stark ist die Performance des eingesetzten Servers?

[brandelh]

Ich habe mir vor .... ZIG ... Jahren einen Basic Compiler für meinen TI99 gekauft, weil ich dachte da wird alles viel schneller ...
und war so enttäuscht, dass ich dem Hersteller meinen Beispielcode und die Messergebnisse übermittelt habe ...
Antwort "Was erwarten Sie von einem Compiler, wenn Ihr Programm auf Benutzereingaben oder Bildschirmausgaben wartet ..."

[Jan]

Herbert,

das dürfte in diesem Fall reletiv egal sein. Carlo schrieb ja, das die Werte in Arrays und Variablen liegen. Also eher alles InMemory. Haupsache das ist nicht zu viel, daß das System anfangen muß zu swappen.

Ansonsten ist das natürlich richtig. Bei Datenbanken gilt ja noch mehr als sonst wo: Es kann nie schnell genug sein. Schneller ist immer besser als schnell.

Jan

[ramses]

Danke für eure Gedanken.

Momentan bin ein wenig festgefahren. Bei dem Programm geht es um eine Berechnung die seit Jahren auf einem 486 Rechner läuft.
Wenn ich das ganze mit xbase++ Anhand der Original-Doku der Formeln / Ablauf nachbaue und sogar die Aufgaben Ein/Ausgabe der Daten nicht berücksichtige komme ich mit der Rechenzeit nicht mal annäherend in den Zeitberech die der alte 486 Rechner benötigt um die ganze Aufgabe mit Ein/Ausgabe zu erledigen. Das muss doch auf aktueller Hardware irgenwie doch schneller gehen als mit der alten Kiste die nur etwa 100 Mhz Takt hatte .....

[Koverhage]

Carlo,
welche Programmiersprache auf dem 486 ?
Die Berechnung könnte ja auch in c++ erfolgen

[Marcus Herz]

Ich hatte noch zu Clipper Zeiten ähnliche Probleme. Hab dann die Berechnungen mit C implementiert und das war rasend schnell. Auch später so nach Xbase übernommen. Hatte versucht, das mit Arrays in Xbase abzulösen, aber die ersten Versuche waren nicht überzeugend, ich habs dann bei C belassen. Das war aber vor 12 Jahren, mit anderer Hardware, OS und Xbase Version.
Ich weiß nicht, wie Alaska numerische Werte verarbeitet, vermute es sind eher Objekte als simple Fiießkomma Zahlen oder ähnliches, weil Zahlen auch eine Eigenschaft der Länge/Dez. besitzen.
Wenn viele Berechnungen, dann kann das schon in C schneller sein, es dürfen nur nicht zuviele Aufrufe sein, weil die ja auch wieder Performance benötigen. Optimal ist dann eine Aufruf für die komplette Berechnung.

[ramses]

Hallo Klaus
Hallo Marcus

das weiss ich noch nicht welche Programmiersprache es ist. Nach dem letzten Ausfall des Raid-Arrays wurden nur noch die Binaries aus der letzten Tagessicherung auf die neuen Platten kopiert. Da es auf einem SCO-Unix läuft welches das Datum Jahr jetzt als 16.04.120 anzeigt gehe ich davon aus dass es C oder Assembler sein könnte.

Auch meine Versuche die Berechnung in XBase abzubilden sind nicht überzeugend. Es ist noch immer um das XX fache langsamer als das Original....
Von den vorkommenden Zahlen her reichen die 32-Bit Register zum Rechnen eigentlich aus.
Auf dem Entsorgungshof hab ich heute ein passendes Mainboard mit ISA-Slots gefunden ich bin jetzt daran mit den alten Bänder und einem alten Bandlaufwerk ein komplett Sytem wiederherzustellen. Da müssten die Sourcen drauf sein.

[ramses]

Inzwischen habe ich es geschafft den alten Sourcecode zu finden und diesen C/ASM Code in eine DLL zu packen.
Die ganzen Berechnungen laufen nun auch einiges schneller als auf dem UR-System.
Zum Glück hatte ich Hilfe eines Freundes der sich mit C auskennt und damit Arbeitet.

Es war jedoch gar nicht so einfach den alten Code anzupassen wie sich das jetzt anhört .....
Einige Probleme mussten gesucht und gelöst werden.

Bei einem Fehler der uns lange beschäftigte vermuteten wir Probleme mit xbase 2.0 deshalb
haben wir (aus purer Verzweiflung) sogar xbase 1.90.355 aus der Mottenkiste geholt. Das Problem war dann aber doch nicht Xbase 2.0
sondern ein Timigproblem.

Jedoch war der Versuch wieder mit der 1.90.355 zu arbeiten nicht ganz ohne. Ich war echt überwätigt.
Die ganze aktuelle APP die zu einer EXE gelinkt 45MB gross wird liess sich fehlerfrei compilieren und
läuft absolut einwandfrei.
Postgres und alles läuft einzig der SMTPClient() funktioniert nicht mit Port 465.
Die verbesserten Grafikfunktionen der 2.0 benutze ich, wie vieles anderes aus der 2.0, seit einiger Zeit
nicht mehr da vieles in den Browser, ot4xb oder eigenen Code und Klassen verlagert wurde.
Oder schon lange in anderen Tools wie z.b. das geniale und super schnelle xb2net zuhause sind.

Gefühlsmässig startete und lief das Programm unter 1.9.355 schneller und flotter als unter der aktuellen 2.00.1185 .....
Weiter haben wir dann keine weiteren Vergleiche mehr gemacht, weil das Mailen ist eine zentrale Aufgabe die wir
unbedingt benötigen und deshalb auch keinen vollständigen Funktionstest durchführen wollten.

Es erstaunt doch sehr. Dass der Compiler aus der Mottenkiste noch ein problemlos laufendes Programm erzeugt
das fehlerfrei und auf den ersten Blick flotter abläuft ..... auch auf W10 / W2019

......

[Tom]

Ich stelle auch immer wieder eine gefühlte Behäbigkeit fest, und wir haben die 1.9SL1 sogar noch im Produktiveinsatz. Aber unsere Leistungsmessinstrumente sagen regelmäßig, dass die 2 unterm Strich ein wenig schneller ist. Allerdings marginal, im unteren einstelligen Prozentbereich.

[Marcus Herz]

Hi Tom
Welche Leistungstests macht ihr da?
- Graphikausgaben
- Create von Objekten mit Win Resource anfordern
- Tabellezugriffe dürften ja gleich sein, weil da ja ein Server im Hintergund ist.
- ...?
Hast du mehr Infos dazu?

[Tom]

Hallo, Marcus.

Wir haben eine subjektive und situative Leistungsmessung entwickelt, die diverse Aspekte untersucht, indem einige Vorgänge in Ausschließlichkeit und mit hoher Prozesspriorität gestartet werden. Das haben wir dann auf vielen Maschinen unter Optimalbedingungen laufen lassen und die Werte eingesammelt, um eine Referenz für den Vergleich zu haben. Die Werte und Erhebungen werden regelmäßig der Hardwareentwicklung angepasst. Das Ergebnis ist ein subjektiver Wert, der uns Auskunft über Optimierungsmöglichkeiten oder mögliche Bremsen liefert. Hier ein Beispiel.

leistungsmessung.png (56.6 KiB) 10153 mal betrachtet

[Marcus Herz]

Hi Tom
Danke, interessant. Obgleich man nicht weiß, welcher Code dahintersteckt. (Ich bin halt neugierig..)

Aber:

Das wäre doch auch ein interessantes Projekt für offene, gemeinsame Entwicklung, als Thema bei nächstem Treffen.

[ramses]

Das grösste Problem ist doch eigentlich das:
Auch bei mehreren absolut *unabhängig* voneinader ablaufenden Threads kann nur 1 CPU Kern wirklich genutzt werden.
So kommts z.B. dazu dass ein Server 20 Kerne hat jedoch nur 1 CPU Kern wirklich genutzt wird. Entsprechend schlecht ist auch die Performance und die Ausbeute. Ausbeute: 5% ....

Sicher in der Clipper Welt spielte das noch keine grosse Rolle. Heute arbeiten wir mit Threads und ein Programm übernimmt immer mehr verschiedene Aufgaben so verschärft sich das ganze ständig. ....

[Tom]

@Carlo: Wenn ein Server mit 20 (oder eher 24) Kernen dafür genutzt wird, eine Anwendung per RDP bzw. als Terminal Server zu hosten, dann verteilen wir zumindest die Kerne auf die Instanzen der Anwendung. Und der Bottleneck sind bei Geschäftsanwendungen sowieso meistens die Daten. Es geht bei solchen Leistungsmessungen regelmäßig aber vor allem darum, a) Kunden-Mitarbeitern Argumente für Hardwareinvestitionen zu verschaffen, b) hyperaktive Virenscanner zu erwischen und c) krasse Konfigurationsfehler auszumachen. Wir messen das nicht, um unsere Anwendung zu optimieren.

[ramses]

@Tom: Sicher. Wir laden auch mehrere Instanzen der Service App (Xbase Programm) die dann verschiedenen Kernen zugeordnet werden. Das ganze dazunötige Load-Balancing und die ganze Einrichtung ist schon möglich ..... aber umständlich.

Mit den Web-Apps haben wir wenigstens keine Sorgen mehr mit Virenscannern oder Konfigurationsproblemen. Weil die Daten auf einem Unix Server liegen reicht bereits ein out of the Box Windows Server mit minimalen Anpassungen zum Betrieb völlig aus.

Eleganter wäre es wenn dies die Programmiersprache bereits ermöglichen würde Thread's auf verschiedenen Kernen zu starten.
Das wäre mal eine echte Neuerung ...............