RPG Programm durch Verwendung von DS für I/O Operationen

[Radinator]

Also würde ich am Ende nur einen unterschied feststellen, wenn ich pro Lesezugriff mehrer 10 Felder (30+) bewege?

[Fuerchau]

Im Nanosekundenbereich wohl ja.
Allerdings kann der %Timestamp nur Millisekunden und der SQL-Timestamp nur Microsekunden.
Da ist es schon schwierig in einer Multiuser-/Multijobumgebung zu messbaren Aussagen zu kommen.
Schließlich muss man ja auch wissen, was denn sonst so gerade läuft und ob man alleine auf dem System wirbelt.

Optimierungen gibt es häufiger im IO-Bereich durch vernünftige Verwendung von Indizes oder in der Array-Verarbeitung mit Lookup/%Lookup eher mit sortierten Arrays und Binär-Suchen zu arbeiten wenn es von der Aufgabe her möglich ist.
Gerade %lookup erlaubt ja die Angabe der max. zu verwendenden Einträge an Stelle aller Einträge zu durchforsten.
Es gibt da durchaus Potential Anwendungen zu entschlacken und damit zu beschleunigen und das liegt weniger daran ob man mal einen Move mehr oder weniger macht.

[Radinator]

Deine Aussage bezüglich der %lookup Funktion entnehme ich, dass man solche Abfragen oder Programme auch beschleunigen kann, indem man z.B. bei meinem Fall zu einem Hauptartikel (bzw Material) alle Zutaten(Unter-Artikell, Arbeitsgänge, usw) nicht einzeln aus der Datenbank lesen und verarbeiten soll, sondern sich alle benötigten Sachen in Tabellen bzw Arrays laden soll und auf diese dann per %tlookup/%lookup zugreifen soll?

Hatte das bisher immer vermieden, da mein Kollege mir immer gesagt hat, ich soll die Daten möglich nur aus den Datenbanken und nicht "ins Programm laden".

Ich mein auf der AS400 auf der ich schreibe werden die PFs nur über LFs abgefragt, die dann eine Sortierung nach dem entsprechenden Kriterium haben (logisch *augenroll*).

Aber wenn ich die Zugriffszeit durch sortierte LFs nicht noch weiter senken kann und sich der Bereich, in dem ich eine Verbesserung durch Verwendung von Datenstrukturen im Resultfeld erzielen kann, sich nicht im Sekundenbereich befindet, dann glaube ich, dass die Version mit SQL doch am besten ist.

[Pikachu]

Wenn ihr genügend Arbeitsspeicher habt, kann auch ein SETOBJACC auf die entsprechenden Dateien und Zugriffspfade einiges bringen.

[Fuerchau]

SETOBJACC hat sich durch die intelligenteren Cachefunktionen längst überholt. Ausßerdem lohnt das nur, wenn man dafür eigene Speicherpools definert, die dem Paging dann nicht unterliegen.

Eas Arrays angeht, so habe ich nicht geagt, dass man alles und jedes cachen muss, da für einen Binärzugriff das Array auch jedesmal neu sortiert werden muss.
Dies lohnt eher für Arbeitsarrays, wenn diese sich sortieren lassen und eine Suche mit "=" erfolgt.
Für andere Suchen gibt es keine Binärsuche.
Allerdings ist dies bei Tabellen bis 100 Elementen auch nahezu unmessbar.

Wie bereits gesagt, SQL ist beim Suchen von Information und dem eingeschränkten Lesen (also nur gefilterte Ergebnisse) meist schneller als native Funktionen. Ins besonders wenn Index-Only-Access zum Tragen kommt. Nicht zu vergessen, VARLEN-Felder immer in ihrer Gesamtheit im Datensatz zu definieren da somit je Feld u.U. kein 2. IO erforderlich ist (Ausnahme LOB's, da gehts ja nicht anders).

[hel400]

...
SETOBJACC hat sich durch die intelligenteren Cachefunktionen längst überholt
...

Naja, ganz so ist es nicht (oder besser gesagt - GANZ IM GEGENTEIL!!)

Auch die besseren Cachingmethoden können ein gezieltes Objektladen - dort wo es sinnvoll ist - nicht ersetzen.

Aus diesem Grund kann man das, was SETOBJACC macht, seit V7R1 auch direkt in div. Dateibefehlen durchführen (CHGPF...) und seit V7R2 hat das Ganze auch Einzug in die SQL-Welt gefunden (create/alter table etc..).

Überholt ist die SETOBJACC Funktionalität also nicht, sondern sogar noch erweitert worden.

[Fuerchau]

Aber wie gesagt, ohne eigenen Cache (also nicht *Base o.ä.) nicht sinnvoll, da dann ja wieder die Daten verdrängt werden können.
Und ehrlich, wenn genügend Hauptspeicher vorhanden ist, erledigt sich dies wirklich von selber ohne dass ich mir darüber Gedanken machen muss.
Da gibt es andere Optimierungen (Business-Logik, Asynchronverarbeitung, ...).

Klar kann ich mir über breitere Autobahnen Gedanken machen an Stelle von sinnvollem Verkehrsmanagement.