Grosse CodeUnit aufteilen?
5. Januar 2007 09:05
Ich habe in einer Anwendung eine sehr grosse CodeUnit mit sehr vielen Funktionen drin.
Da hier auch immer wieder Funktionen dazukommen, wird diese CU immer unübersichtlicher.
Was ich mich nebst der Unübersichtlichkeit (damit kann man aber umgehen, wenn man die CU etwas kennt) frage ist, ob es von der Performance her besser wäre, eine grosse CU aufzuteilen in mehrere kleinere. Ich muss dazu noch sagen, dass es in dieser CU eine Hauptroutine gibt, die dann die vielen kleinen SubFunktionen aufruft. Und diese könnte man natürlich auslagern.
Hat da jemand Erfahrungen dazu?
Da hier auch immer wieder Funktionen dazukommen, wird diese CU immer unübersichtlicher.
Was ich mich nebst der Unübersichtlichkeit (damit kann man aber umgehen, wenn man die CU etwas kennt) frage ist, ob es von der Performance her besser wäre, eine grosse CU aufzuteilen in mehrere kleinere. Ich muss dazu noch sagen, dass es in dieser CU eine Hauptroutine gibt, die dann die vielen kleinen SubFunktionen aufruft. Und diese könnte man natürlich auslagern.
Hat da jemand Erfahrungen dazu?
5. Januar 2007 10:56
Wenn nicht immer alle Funktionen verwendet werden, kann es besser sein, diese in kleine Objekte aufzuteilen, weil dann wirklich nur das geladen wird, was auch benötigt wird.
Von der Laufzeitperformance ist es am besten, überhaupt keine Funktionen zu verwenden und einen fürchterlichen Spaghetticode zu schreiben. Die "Wartungsperformance" nimmt dann aber natürlich spürbar ab ( genau wie die Laune des Programmierers
).
Von der Laufzeitperformance ist es am besten, überhaupt keine Funktionen zu verwenden und einen fürchterlichen Spaghetticode zu schreiben. Die "Wartungsperformance" nimmt dann aber natürlich spürbar ab ( genau wie die Laune des Programmierers
).
5. Januar 2007 11:22
Danke für die Antwort.
Da praktisch immer alle Funktionen durchlaufen werden, würde die Aufteilung nur noch Sinn machen aus der Sicht der Übersichtlichkeit.
Und mir die Laune mit Spagghetticode verderben mag ich nicht
Da praktisch immer alle Funktionen durchlaufen werden, würde die Aufteilung nur noch Sinn machen aus der Sicht der Übersichtlichkeit.
Und mir die Laune mit Spagghetticode verderben mag ich nicht
5. Januar 2007 12:13
Wenn wir schon beim Thema sind:
Ab wann wird das Codeunit überhaupt in den Speicher gerufen? Beim erstmaligen Aufruf oder schon durch die reine Variablendeklaration?
Ab wann wird das Codeunit überhaupt in den Speicher gerufen? Beim erstmaligen Aufruf oder schon durch die reine Variablendeklaration?
5. Januar 2007 12:55
Zum Thema Performance und Übersichtlichkeit gibt es einen relativ
einfachen Weg hier zu optimieren, der meist übersehen wird.
In einer CU kann man die "internen" Funktionen auf in ihrer Eigenschaft auf Local setzen.
Dies hat zur Folge, das man
1. die "internen" Funktionen über den
Obect Designer nicht nach aussen sichtbar macht
2. Der Aufruf der Funktion schneller erfolgen kann, da schon beim
durchsuchen der "localen" Listen der EIntrag gefunden wird.
einfachen Weg hier zu optimieren, der meist übersehen wird.
In einer CU kann man die "internen" Funktionen auf in ihrer Eigenschaft auf Local setzen.
Dies hat zur Folge, das man
1. die "internen" Funktionen über den
Obect Designer nicht nach aussen sichtbar macht
2. Der Aufruf der Funktion schneller erfolgen kann, da schon beim
durchsuchen der "localen" Listen der EIntrag gefunden wird.
5. Januar 2007 13:05
Das heisst, eine CU wird schneller abgearbeitet, wenn die Funktionen nur local, also innerhalb der CU, verfügbar gemacht werden?
5. Januar 2007 14:07
Ganz nebenbei gehört das zum "Programmierknigge" dazu, Funktionen nur dort sichtbar zu machen, wo sie gebraucht werden.Ingo Roth hat geschrieben:Zum Thema Performance und Übersichtlichkeit gibt es einen relativ
einfachen Weg hier zu optimieren, der meist übersehen wird.
In einer CU kann man die "internen" Funktionen auf in ihrer Eigenschaft auf Local setzen.
Dies hat zur Folge, das man
1. die "internen" Funktionen über den
Obect Designer nicht nach aussen sichtbar macht
2. Der Aufruf der Funktion schneller erfolgen kann, da schon beim
durchsuchen der "localen" Listen der EIntrag gefunden wird.
Andere Programmiersprachen bieten im Gegensatz zu Navision eine Fülle von Deklarationsmöglichkeiten für Funktionen, Unterfunktionen (die vermisse ich in C/AL am meisten) und deren Variablen.
C/AL kennt nur global und lokal, in anderen Sprachen kann eine Variable innerhalb von einer Gruppe von Funktionen global sein.
Jein.rotsch hat geschrieben:Das heisst, eine CU wird schneller abgearbeitet, wenn die Funktionen nur local, also innerhalb der CU, verfügbar gemacht werden?
Wenn du eine Codeunit-Funktion aufrufst, muss diese ja global deklariert sein, damit du sie überhaupt aufrufen kannst. Also durchsucht (zumindest folgere ich das so) C/AL in diesem Codeunit zunächst NUR die globoalen Funktion. Deklararierst du innerhalb dieser Codeunit also noch lokale Funktionen, können diese getrost übersprungen werden.
Und wenn eine Codeunit-Funktion eine andere Funktion desselben Codeunits aufrufst, werden (glaub ich) zunächst nur die lokalen Funktionen durchsuchst; erst dann die globalen.
Jetzt bin ich aber gespannt, ob das richtig war *G*
In Delphi wars zumdinest so *R.I.P.*
5. Januar 2007 14:42
"Dem Programmierknigge" kann ich nur zustimmen.
Ich habe aber mal ein paar Codeunits zu Untermauerung getestet.
bei vier Local/Global Deklarierten Test-Funktionen ist die Local-Variante
die etwas schnellere.
Dann habe ich noch die Übergabe eines Integer Parameters
auf VAR Deklariert.
Dies hat noch einiges mehr an Performance gebracht !
Sollte ja auch so sein, da jetzt nur noch ein "Zeiger" auf die Ursprüngliche
Var an die Funktion übergeben wird.
Also für beste Performance:
1. Interne Functionen auf Local
2. Bei Functionen die Parameter als VAR deklarieren.
Ich habe aber mal ein paar Codeunits zu Untermauerung getestet.
bei vier Local/Global Deklarierten Test-Funktionen ist die Local-Variante
die etwas schnellere.
Dann habe ich noch die Übergabe eines Integer Parameters
auf VAR Deklariert.
Dies hat noch einiges mehr an Performance gebracht !
Sollte ja auch so sein, da jetzt nur noch ein "Zeiger" auf die Ursprüngliche
Var an die Funktion übergeben wird.
Also für beste Performance:
1. Interne Functionen auf Local
2. Bei Functionen die Parameter als VAR deklarieren.
5. Januar 2007 15:23
Dem stimme ich zu.
Einzig beim deklarieren der Parameter als VAR bin ich vorsichtig. Ich deklariere hier nur jene Variablen als VAR, die es auch sein müssen. Die Gefahr, irrtümlich den Wert eines Übergabeparameters zu ändern ist mir zu gross.
Einzig beim deklarieren der Parameter als VAR bin ich vorsichtig. Ich deklariere hier nur jene Variablen als VAR, die es auch sein müssen. Die Gefahr, irrtümlich den Wert eines Übergabeparameters zu ändern ist mir zu gross.
5. Januar 2007 15:31
Die Parameter als VAR zu deklarieren bringt viel Performancegewinn, besonders wenn große Recordvariablen übergeben werden. Man muss dabei aber immer die Funktion checken, ob Felder dort modifiziert werden. Bei VAR hat dies sofort Auswirkungen auf den Urspungswert, ohne VAR nicht.