Litreatur iseries --> z. B. Performance

[camouflage]

Und stimmt es heute noch, dass man interne Datenstrukturen möglichst kein halten soll, da die sonst zu viel Spieicher/Performance benötigen - habe gehört, dem wäre heute nicht mehr so, man kann also ruhig mal 100 oder 200 Stellen frei lassen, um für eine neue Variable die Datenstruktur nicht immer anpassen zu müssen und somit nicht immer alle Programm neu compilieren zu müssen....

Kannst Du mal verraten auf welchem Wissensstand (Release/Modell) Du bist...

[Pikachu]

Was heute immer noch was bringt, ist ein SETOBJACC auf Datenbankdateien direkt vor dem Aufruf eines Programms, das diese Dateien liest oder aktualisiert.

Außerdem sind die entsprechenden Befehle wie zum Beispiel DIV, MULT, SCAN, ... meist viel schneller als ein EVAL mit entsprechender Berechnung.

[peterspeer]

Danke für Eure Antworten.
@Camouflage: Das ist ja das Problem, entwickelt wird auf V7, mit SQL und ILE usw. aber Infos über eben solche Dinge sind noch auf dem Stand 1999...da hat man sich mal über solche Dinge Gedanken gemacht.

Damals hies es auch jeder Read in RPG ist schneller als ein SQL-Fetch (auch das sollte heute wohl nicht mehr stimmen).

Das mit den Read-Operationen und dem Datenbank-design ist klar.

Aber ich hatte halt noch so im Hinterkopf, dass man eben auch Dinge wie Ihr schon genannt habt noch Effekt haben. (Ocur, Scan, Lokup, Move... was ist ggf. flotter...)

Aber das scheint ja nicht mehr so wirklich ausschlaggebend zu sein.

Nochmals Danke !
Gruß
Peter

[B.Hauser]

... da machen sich Leute Gedanken darüber ob ein MOVE schneller als ein EVAL ist, und überlesen 100.000 Zeilen nur um einen einzigen Datensatz zu finden.

SQL Performance Analyse ist ein weitgefächertes Thema, zu dem es durchaus viele Artikel und Redbooks gibt.

Hier einige Links wo du fündig werden kannst:
Redbooks - SQL Performance
Online Information Center - Database Information Finder

Birgitta

[Fuerchau]

Wer sich über sowas Gedanken macht verwendet sicherlich kein SQL so dass ihm mit dieser Literatur auch nicht geholfen ist .

Und wer sich ein bisschen mit MI beschäftigt hat weiß auch, das es zwischen MOVE und einfachem EVAL keinen gravierenden Unterschied gibt.

Irgendwo hatte ich mal gesehen, dass folgende Befehle zu immer dem selben MI-Befehl führen:

FELDA ADD FELDB FELDB
ADD FELDA FELDB
eval FELDB = FELDA + FELDB
eval FELDB += FELDA

Bei Zeichenfeldern gibt es nur dann einen Unterschied, wenn das Ziel größer als die Quelle ist (wobei EVALR dem MOVE(P) und EVAL dem MOVEL(P) entspricht).
Sicherlich kann ich hier Zeiten einsparen wenn ich anstelle von

MOVE *BLANKS FELDX
MOVEL FELDA FELDX

gleich

MOVEL(P) FELDA FELDX

verwende.
Bei der Gesamtlaufzeit eines Programmes/Programmteiles kann ich auf diese Weise sicherlich ein paar Nanosekunden rausholen.

Aber ich kenne auch noch viele Programme, die es sich wirklich einfach machen, Dateien z.B. per IP komplett durchzulesen um einige wenige Sätze zu verarbeiten. Hier lassen sich mitunter ganze Stunden optimieren.
Und da hilft einem leider kein Handbuch.

[RobertMack]

Denkt auch jemand über die Performance von Entwicklern nach? Schließlich ist das der teuerste Posten im Gesamtbudget.

Übersichtliche und leicht wartbare Programme mit sprechenden MOVEs, ADDs, kurzen EVALs und kommentierten Zwischenergebnissen sind bares Geld wert. Wer schon mal einen fremden EVAL ala
=((KRYPT1/(DS1(I)+FLDX))-(KRYPT1/(DS1(I)+FLDY)))*(KRYPT2/100) recherchieren oder debuggen musste, weiß wovon ich rede. Hier gehen heutzutage die Millisekunden flöten... ;-)

scnr

[Fuerchau]

Ich habe noch keine Firma kennengelernt, die sich im IT-Umfeld über Ehda-Kosten je Gedanken gemacht hat.

[peterspeer]

Danke für Eure Antworten.
Gut, zugegeben, bei einem Movel oder Eval Zeit einzusparen wird wohl kaum messbar sein.
Die groben Dinge (DB-Design oder Zugriffe für wenige Datensätze) oder Nutzung von ILE, SQL etc. sind alle klar, ich wollte nur mal wissen, ob es noch so ein paar versteckte "Tricks" und "Tücken" gibt.

@Fuerchau: Doch, SQL und Embedded-SQL wird schon seit Anfang 2000 genutzt....nur auch hier weniger vor dem Hintergrund der Performance.

Und genau, da (bei der Performance) hätt ich gedacht hier was "verschlafen" zu haben.

Viele Grüße
Peter Speer

[Pikachu]

Damals hies es auch jeder Read in RPG ist schneller als ein SQL-Fetch (auch das sollte heute wohl nicht mehr stimmen).

Das wird immer noch stimmen, aber es geht auf neueren Maschinen heute eben alles viel flotter, und der Unterschied fällt deshalb meistens kaum auf.