Wird Skript durch verwenden von Funktionen langsamer?

WICHTIG: Der Betrieb von goMatlab.de wird privat finanziert fortgesetzt. - Mehr Infos...

Partner:

Forum

Option

[Erweitert]

• Diese Seite per Mail weiterempfehlen

Gehe zu:

lukel

Forum-Anfänger


	Beiträge: 39

	Anmeldedatum: 27.08.15

	Wohnort: ---

	Version: R2015b

Verfasst am: 03.02.2016, 13:13 Titel: Wird Skript durch verwenden von Funktionen langsamer?

Hallo,

ich teile lange Skripte gerne in Unterfunktionen auf, um eine bessere Übersichtlichkeit zu erhalten.

Wird die Durchlaufzeit des Skriptes dadurch langsamer, weil Matlab ja immer erst die Funktion laden muss?

viele Grüße

lukel

Jan S

Moderator


	Beiträge: 11.057

	Anmeldedatum: 08.07.10

	Wohnort: Heidelberg

	Version: 2009a, 2016b

Verfasst am: 03.02.2016, 18:09 Titel: Re: Wird Skript durch verwenden von Funktionen langsamer?

Hallo lukel,

Da gibt es verschiedene Aspekte:
1. Beim ersten Aufruf einer Funktion wir das M-File von der Festplatte gelesen und übersetzt, was "sehr" viel Zeit benötigt - das kann also acuh schon mal 0.5 sec sein, wenn das File wirklich groß ist (>10'000 Zeilen) und die Platte gerade auf anderweitig verwendet wird.
2. Nun kann man die Funktion in mehrere Unterfunktionen aufteilen, die entweder in einem M-File liegen, oder sie in mehrere M-Files verteilen. In beiden Fällen wird fast die gleiche Anzahl von Bytes eingelesen und Zeilen übersetzt. Der Unterschied ist also marginal.
3. Der Aufruf einer Unterfunktion kostet Zeit, denn Matlab muss die Einsprung-Adresse aus einer Tabelle besorgen und sich um die Übergabe der Variablen kümmern. Eine Unterfunktion im gleichen M-File wird messbar schneller aufgerufen, weil die Tabelle dafür kürzer ist.
4. Sowie man an irgendeiner Stelle im Code eval verwendet, kann der Übersetzer die Funktions-Tabellen nicht mehr effizient auswerten, denn es könnte ja etwas wie dies sein:

Code:

eval('sin = 10;')
y = sin(1);

Funktion ohne Link?

Nun wäre unklar, ob der sin Befehl oder die Variable "sin" gemeint ist. Dadurch wird die JIT-Acceleration behindert und der Code kann in der Größenordnung Faktor 100 langsamer laufen.
5. Der Overhead beim Aufruf von Funktionen spielt daqnn eine Rolle, wenn dies Milliarden Mal in einer Schleife geschieht. So ist z.B. der Aufruf des M-Funktion mean(x) messbar langsamer als die BuiltIn-Funktionen sum(x)/numel(x) , aber es handelt sich nur um Micro-Sekunden.
6. Es gilt die Regel:

Zitat:

Programm-Zeit = Programmier-Zeit + Debug-Zeit + Dokumentations-Zeit + Laufzeit

Ein M-File mit 10'000 Zeilen lässt sich nicht sinnvoll debuggen. Da bringt es gar nichts, wenn es eine Sekunde schneller läuft, man dafür aber zwei Wochen braucht, um einen Fehler zu finden.
Wenn man Code-Teile sinnvoll in eigene M-Files auslagert und ausgiebig testet, kann man sie eventuell später auch für andere Programme verwenden. Und dann fällt beim nächsten mal "Programmier-Zeit + Debug-Zeit + Dokumentations-Zeit" weg!

Ich habe sehr viele Programmier-Projekte scheitern sehen, weil die Programme wegen zu früher Optimierung der Laufzeit im absoluten Chaos versunken sind. Die Komplexität des Codes nimmt explosionsartig zu und irgendwann ist der Überblick weg. Eines dieser Projekte war eine neue Verwaltungssoftware für eine Krankenkasse und es wurde dabei mal eben 1 Millarde (!) Euro verpulvert.

Aus diesen Gründen rate ich zu handlichen und übersichtlichen Unterfunktionen, die am besten noch von anderen Programm genutzt werden können - oder zumindest die Möglichkeit bieten sie später dahingehend anzupassen.
Wenn dann ein Programm fertig ist und man mit dem Profiler feststellt, welcher Abschnitt zu viel Rechenzeit benötigt, kann man dort ansetzen und aus einem externen M-File eine lokale Unterfunktion zu erstellen, oder den Inhalt in die Schleife einzufügen um den Funktions-Overhead einzusparen. Oder man Mex-t den Teil gleich.

Gruß, Jan

ich teile lange Skripte gerne in Unterfunktionen auf, um eine bessere Übersichtlichkeit zu erhalten.

Wird die Durchlaufzeit des Skriptes dadurch langsamer, weil Matlab ja immer erst die Funktion laden muss?

viele Grüße

lukel[/quote]

lukel

Themenstarter

Forum-Anfänger


	Beiträge: 39

	Anmeldedatum: 27.08.15

	Wohnort: ---

	Version: R2015b

Verfasst am: 04.02.2016, 09:58 Titel:

Vielen Dank

Eine Frage hätte ich dazu noch:
Was meinst mit "unterfunktion im gleichen M-File"?

Das ich in dem Skript, in dem ich die Funktion verwenden möchte auch schon am Ende die Definition definiere?

Jan S

Moderator


	Beiträge: 11.057

	Anmeldedatum: 08.07.10

	Wohnort: Heidelberg

	Version: 2009a, 2016b

Verfasst am: 04.02.2016, 13:02 Titel:

Hallo lukel,

Ich verwende grundsätzlich niemals Scripte, weil sie unübersichtlich sind. Variablen in anderen Workspaces zu überschreiben bleibt immer eine ernste Fehlerquelle. Wenn man mal 20 Scripte nacheinander laufen hat und plötzlich "sum(1:10)" Fehlermeldungen erzeugt, weil man in irgendeinem Script irgendwo "sum=5" definiert hat, ist man ewig am Suchen.

Deshalb verwende ich nur Funktionen, also M-Files, die mit "function" beginnen, und niemals Scripts. In M-Functions kann man Unter-Funktionen definieren, die dann nur innerhalb dieses M-Files bekannt sind. So kann man sich bei Bedarf eine eigene "sin" Funktion schreiben, ohne gleich alle anderen Matlab-Files damit zu verwirren. Da diese Unterfunktionen dann auch nicht erst unter allen möglichen M-Files gesucht werden müssen, ist der Overhead kleiner.
Aber wie gesagt: Um die Unter-Funktionen dann auch von anderen Programmen aus zu nutzen, müssen sie in eigene M-Files ausgelagert werden.

In Scripts kann man keine Unter-Funktionen erstellen.

Gruß, Jan

lukel

Themenstarter

Forum-Anfänger


	Beiträge: 39

	Anmeldedatum: 27.08.15

	Wohnort: ---

	Version: R2015b

Verfasst am: 04.02.2016, 13:19 Titel:

Achso

aber am Ende brauchst du doch ein Script, in dem der Ablauf programmiert, wann und in welcher Reihenfolge die Funktionen benutzt werden sollen ?

Winkow

Moderator


	Beiträge: 3.842

	Anmeldedatum: 04.11.11

	Wohnort: Dresden

	Version: R2014a 2015a

Verfasst am: 04.02.2016, 13:23 Titel:

nein. du rufst einfache eine funktion auf die dann deine unterfunktionen aufruft in der reihenfolge wie du willst. du hast also kein main.m als skript sondern als funktion.
_________________

richtig Fragen

Jan S

Moderator


	Beiträge: 11.057

	Anmeldedatum: 08.07.10

	Wohnort: Heidelberg

	Version: 2009a, 2016b

Verfasst am: 04.02.2016, 14:14 Titel:

Hallo lukel,

Genau wie Winkow es beschreibt:

Code:

% In einem M-File
function Result = Main
Data = rand(2,5);
Result = SubFunction(Data);
end

function Y = SubFunction(X)
Y = mean(X);
end

Funktion ohne Link?

Wenn man dies nun vom Commandwindow aufruft, wird dort nichts überschrieben:

Code:

% Im Command-Window oder einer anderen Funktion:
X = 5;
Data = 'hallo';
Result = Main;
disp(X); % ==> 5
disp(Data); % ==> 'hallo'

Funktion ohne Link?

Gruß, Jan

lukel

Themenstarter

Forum-Anfänger


	Beiträge: 39

	Anmeldedatum: 27.08.15

	Wohnort: ---

	Version: R2015b

Verfasst am: 04.02.2016, 15:42 Titel:

Ok das ist ja eigentlich ganz schön praktisch... müsste ich mir nur umgewöhnen Very Happy

aber dann muss man beim kopieren der Funktion in andere Ordner immer alle erstellten Unterfunktionen mitnehmen oder?

Winkow

Moderator


	Beiträge: 3.842

	Anmeldedatum: 04.11.11

	Wohnort: Dresden

	Version: R2014a 2015a

Verfasst am: 04.02.2016, 17:19 Titel:

Zitat:

aber dann muss man beim kopieren der Funktion in andere Ordner immer alle erstellten Unterfunktionen mitnehmen oder?

das kommt drauf an. eigendtlich schon. wenn du aber selber nützliche funktionen schreibst die du öfter benutzt in all deinen programmen kannst du dir dafür auch einen seperaten ordner erstellen und diese dann beim matlab path zufügen. sihe dazu auch addpath path oder pathtool etc
_________________

richtig Fragen

Jan S

Moderator


	Beiträge: 11.057

	Anmeldedatum: 08.07.10

	Wohnort: Heidelberg

	Version: 2009a, 2016b

Verfasst am: 04.02.2016, 19:40 Titel:

Hallo lukel,

Schaue Dir dazu mal die Ordner-Struktur der Matlab-Toolboxen an, die die haben das bereits sehr effizient gelöst.

Wenn die Unterfunktionen im gleichen File stehen, ist ein Bewegen des M-Files natürlich schmerzfrei.
Wenn die Unterfunktionen als eigene M-Files existieren, sind sie von allen anderen Funktionen aus sichtbar und nutzbar, wenn der dazugehörige Ordner im PATH eingetragen ist (wie Winkow ja schon erklärt hat).
(@Winkow: Sorry, dass ich heute dauernd eins auf Echo mache...)

Zudem gibt es noch "private" Unterfunktionen, die im Unterordner /private stehen. Die sind wieder nur von den Funktionen aus sichtbar, die im Hauptordner stehen. Und jetzt mal alles zusammen:

Code:

% Eine eigene LR-Zerlegung, die aus irgendeinem
% Grund besser ist als die von Matlab:
D:\Matlab\Tools_Mathe\myLR.m
D:\Matlab\Tools_Mathe\AStarSolver.m
D:\Matlab\Tools_Mathe\private\AStarHelper.m

D:\Matlab\Projekt1\projekt1.m
D:\Matlab\Projekt1\helper1.m

D:\Matlab\Projekt2\projekt2.m -> Subfunction helper2

Funktion ohne Link?

Im Ornder Tools_Mathe sammelst Du alle Funktionen, die irgtendwelche Mathe-Aufgaben lösen. Wenn die einmal getestet sind, spart das eine Menge Zeit. Dann fügst Du den Ordner zum Matlab-Pfad hinzu:

Code:

addpath('D:\Matlab\Tools_Mathe', '-end') % IMMER AM ENDE!!!
savepath;

Funktion ohne Link?

Oder mit dem pathtool von Hand.

Die Funktion AStarSolver kann die private Unterfunktion AStarHelper sehen. myLR sieht sie auch, aber von projekt1.m aus ist sie nicht erreichbar. Die \private-Ordner werden NICHT in den PATH eingefügt.
helper1.m kann von überall her aufgerufen werden. Deshalb muss man mit dem Namen vorsichtig sein, damit es hier keine Überschneidungen gibt. Wenn man z.B. eine eigene Funktion strcmp.m schreibt, die einen Bug enthält, kann Matlab nicht mehr ordentlich starten. Darum fügt man sicherheitshalber alle eigenen Ordner HINTER den Ordnern der Matlab-Toolbox ein.

helper2 ist nur innerhalb von projekt2.m aus sichtbar. Das reduziert die Gefahr, dass es aus Versehen von anderer Stelle aus aufgerufen wird. Aber sowie man diese Unterfunktion so allgemein formulieren kann, dass sie z.B. in die eigene Mathe-Toolbox gehört, ist das wieder praktischer.

Wenn man beginnt ein Programm zu schreiben, hat das erstmal nur 100 Zeilen. Hier gleich mit Unterfunktionen und Toolbox-Ordner mit private Subfunctions um sich zu schmeißen, ist natürlich ein Overkill. Wenn das Projekt dann wächst, und das M-File 10'000 Zeilen hat, wird es Zeit für M-Files mit Unterfunktionen innerhalb des Projekt-Ordners. Bei 100'000 Zeilen sind Toolbox-Ordner aber spätestens erforderlich, weil der Code so umfangreich ist, dass man nur noch Einzelteile wirklich in vollem Umfang testen kann (Stichwort: "Unit-Tests"). Während des Schreibens eines Programms gibt es also mehrere Zeitpunkte, an denen man den bisherigen Code praktisch vollständig neu strukturieren muss. Das ist dann auch der Zeitpunkt, zu dem man sich für neue Daten-Strukturen entscheiden kann, z.B. viele Variablen in Structs zusammen zu fassen und so leichter zwischen den Funktionen austauschen zu können.

Unterfunktionen und übersichtlicher Code sind also ein zentraler Punkt beim Software-Engineering, denn Programmieren bedeutet schnell mehr, als einfach nur lauffähigen Code zu schreiben.

Viele Grüße, Jan


Einstellungen und Berechtigungen
Beiträge der letzten Zeit anzeigen:	Du kannst Beiträge in dieses Forum schreiben. Du kannst auf Beiträge in diesem Forum antworten. Du kannst deine Beiträge in diesem Forum nicht bearbeiten. Du kannst deine Beiträge in diesem Forum nicht löschen. Du kannst an Umfragen in diesem Forum nicht mitmachen. Du kannst Dateien in diesem Forum posten Du kannst Dateien in diesem Forum herunterladen

Impressum | Nutzungsbedingungen | Datenschutz | FAQ |

RSS

Hosted by:

Copyright © 2007 - 2025 goMatlab.de | Dies ist keine offizielle Website der Firma The Mathworks

MATLAB, Simulink, Stateflow, Handle Graphics, Real-Time Workshop, SimBiology, SimHydraulics, SimEvents, and xPC TargetBox are registered trademarks and The MathWorks, the L-shaped membrane logo, and Embedded MATLAB are trademarks of The MathWorks, Inc.