Entwickler-Ecke
Sonstiges (Delphi) - Platzersparnis
elundril - Mo 05.03.07 20:23
Titel: Platzersparnis
Spart es eigentlich platz wenn man oft verwendete gleiche Codes auslagert?
als beispiel:
Unausgelagert
1: 2: 3: 4: 5: 6: 7: 8: 9: 10: 11: 12: 13: 14: 15:
| procedure zähltwas; var i: integer; begin Memo1.clear; for i:=0 to 10 do Showmessage('Juhe'); end;
procedure zähltwasundmachwasdabei; var i: integer; begin Memo1.text:='123'; for i:=0 to 10 do Showmessage('Juhe'); end; |
oder:
Ausgelagert
1: 2: 3: 4: 5: 6: 7: 8: 9: 10: 11: 12: 13: 14: 15: 16: 17: 18:
| procedure zähltwas; begin memo1.clear; forschleife; end;
procedure zähltwasundmachwasdabei; begin Memo1.text:='123'; forschleife; end;
procedure forschleife; var i: integer; begin for i:=0 to 10 do Showmessage('Juhe'); end; |
das jetzt nur als grobes beispiel. ich meine natürlich viel kompliziertere und längere prozeduren.
lg el
GTA-Place - Mo 05.03.07 20:25
Nein, sparen tut das nicht viel, aber die Übersichtlichkeit nimmt erheblich zu.
oldmax - Di 06.03.07 10:28
Hi
Nun ja, wenn man die Frage wörtlich nimmt, spart es schon...
Vorteile von Procedures und Functions sind einmal wie schon erwähnt die Übersichtlichkeit, zum anderen, wenn sie stabil laufen, braucht man sich keinen Kopf mehr machen und kann sich darauf verlassen, das sie funktionieren. Muß etwas geändert oder angepaßt werden, dann ist dies nur noch an einer Stelle im Programm notwendig und somit entfällt auch die Suche im Programm und die Einzelanpassung.
Gruß oldmax
Stefan.Buchholtz - Di 06.03.07 10:30
GTA-Place hat folgendes geschrieben: |
Nein, sparen tut das nicht viel, aber die Übersichtlichkeit nimmt erheblich zu. |
Und es macht das Programm erheblich wartungsfreundlicher: Wenn z.B. in dem mehrfach verwendeten Code einen Fehler ist, musst du ihn nur einmal korrigieren, wenn er in einer eigenen Prozedur ist.
Stefan
HelgeLange - Di 06.03.07 11:02
Es kommt drauf an, was du machst. Eine Zählschleife ist denkbar ungeeignet, weil du Dein Programm langsamer machst. Denn lagerst Du sowas aus, kommt dazu dein Call-Aufruf in ASM, dazu müssen Sachen gepushed und gepoppt werden eventuell, Werte verschoben etc... Und der Call selber kostet auch Zeit.
Es gibt ab BDS2006 glaub (oder war es doch schon eher) den inline Befehl, wo Du eine Prozedur als inline deklarieren kannst, damit wird statt dem Callaufruf der Code sozusagen reinkopiert. Das würde machen, was Du willst, n¨mlich übersichtlichkeit etc erhöhen, aber 0 kosten haben. Nur eben Deine Anwendung wird grösser, da es das gleiche ist, als hättest Du den Code direkt n-mal reingeschrieben. Aber gerade bei zeitkritischen Sachen sehr zu empfehlen !
Grüsse
Stefan.Buchholtz - Di 06.03.07 11:15
HelgeLange hat folgendes geschrieben: |
Es kommt drauf an, was du machst. Eine Zählschleife ist denkbar ungeeignet, weil du Dein Programm langsamer machst. Denn lagerst Du sowas aus, kommt dazu dein Call-Aufruf in ASM, dazu müssen Sachen gepushed und gepoppt werden eventuell, Werte verschoben etc... Und der Call selber kostet auch Zeit.
|
Um
Donald Knuth [
http://de.wikipedia.org/wiki/Donald_Ervin_Knuth] zu zitieren:
"Premature optimization is the root of all evil"
Vergiss bei der Softwarenentwicklung kleine Effizienzgewinne wie einen gesparten Prozeduraufruf. Zu 99% wird es keinen spürbaren Unterschied in der Programmlaufzeit machen, aber man handelt sich ganz schnell ein komplett unübersichtliches, nicht mehr wartbares Programm ein.
Stefan
oldmax - Di 06.03.07 14:20
Hi
Ich glaub, was Helge meinte ist der Procedureaufruf aus einer Schleife. Nur da ist es richtig, das sich die Zeiten addieren, und zwar ein paar push, ein paar pop und ein Call dazwischen. grob so umme 30 Taktzyklen. Wenn also aus einer Schleife 10000 mal ein Procedureaufruf kommt......
Bei nem Z80 und 4MHz hat's da schon gedauert.
Aber nich lustig machen, es ist halt so, ein verschwenderischer Code jagd den anderen und in der Summe kommt dann schon mal Langeweile vorm Bildschirm auf, wenn der Rechner mit lahmen Schleifen beschäftigt ist. Es ist aber nichts dagegen zu sagen, wenn innerhalb einer Procedure die Zählschleife ist. Da läuft die ganz normal ab und es ist wesentlich übersichtlicher im Programm. Auch die Schleifenvariable ist lokal deklariert besser aufgehoben und man braucht nicht nachschauen, welche Gültigkeit grad gegeben ist und wo die Zuweisung stattfindet.
Gruß oldmax
IngoD7 - Di 06.03.07 14:40
oldmax hat folgendes geschrieben: |
Nur da ist es richtig, das sich die Zeiten addieren, und zwar ein paar push, ein paar pop und ein Call dazwischen. grob so umme 30 Taktzyklen. Wenn also aus einer Schleife 10000 mal ein Procedureaufruf kommt......
Bei nem Z80 und 4MHz hat's da schon gedauert. |
Ja, 7 1/2 Hundertstelsekunden. Beeil dich mit dem Kaffeetrinken, so lang ist die Pause nicht. :tongue:
oldmax hat folgendes geschrieben: |
dann schon mal Langeweile vorm Bildschirm auf, wenn der Rechner mit lahmen Schleifen beschäftigt ist. |
Die sind aber normalerweise nicht wegen irgendwelcher enthaltenen Calls so lahm geworden, dass du Langeweile bekommst, sondern aus welchen anderen Gründen auch immer. Allermeistens liegen die wahren Optimierungsnotwendigkeiten doch ganz woanders.
BenBE - Mi 07.03.07 16:57
Kleine Anmerkung zum Inline-Befehl von D9 und D10:
Der Inline-Befehl ist immer genau dann in Delphi verwendbar, wenn es für die Optimierung keinen Sinn macht ihn zu verwenden ... Soviel zur Intelligenz des Delphi-Compilers.
Was ich meine ist:
Wenn man in Delphi eine Routine als Inline markiert, dann heißt das nur, dass sich der Compiler hier aussuchen darf, was er damit macht. Es ist kein Zwang, die Routine zu Inlinen ...
Weiter gehend kann man sogar feststellen, dass anhand der Natur zu inlinender Funktionen, das Inlinen nur Sinn macht, wenn die Ausführungszeit der Routine kürzer ist, als der Overhead des Calls. Dies ist immer dann der Fall, wenn die Inline-Routine nur kurz ist und daher sowieso eher in ASM vorliegt, also genau eben NICHT geinlinet werden darf (weil Delphi das nicht unterstützt) ...
Wer durch das Inlinen optimieren will, sollte dies bitte ohne Delphi machen ...
Entwickler-Ecke.de based on phpBB
Copyright 2002 - 2011 by Tino Teuber, Copyright 2011 - 2025 by Christian Stelzmann Alle Rechte vorbehalten.
Alle Beiträge stammen von dritten Personen und dürfen geltendes Recht nicht verletzen.
Entwickler-Ecke und die zugehörigen Webseiten distanzieren sich ausdrücklich von Fremdinhalten jeglicher Art!