Seite 1 von 2
Optimierung durch Macronutzung
Verfasst: 11.05.2006 16:32
von Franky
Hi Leuts
Das neue, Herliche Macro gibt uns allen ne Chance, unsere Codes ohne große umbenennungssessions zu optimieren.
PB meckert nämlich nicht, wenn Macros wie PB-Funktionen heißen.
Mein Erstes Beispiel:
Code: Alles auswählen
Macro RGB2(mpr,mpg,mpb)
(mpr)+(mpg)<<8+(mpb)<<16
EndMacro
k=GetTickCount_()
For a=1 To 100000
For b=1 To 20000
farbe.l=RGB(255,0,255)
Next
Next
p=GetTickCount_()
For a=1 To 100000
For b=1 To 20000
farbe.l=RGB2(255,0,255)
Next
Next
l=GetTickCount_()
MessageRequester("Ergebnis:","Ohne Macro: "+Str(p-k)+Chr(13)+"Mit Macro: "+Str(l-p))
RGB2 in RGB umbenennen, in den Source einbauen, Fertig. Das ganze ist 4 mal so schnell, weil RGB an sich ne kleine Funktion ist und Call daher ne menge ausmacht. Zudem erkennt PB beim Macro, da es direkt eingesetzt wird, dass es sich um einen Konstanten Wert handelt, den es direkt umwandeln kann. Beweis:
Procedure:
; farbe.l=RGB(255,0,255)
PUSH dword 255
PUSH dword 0
MOV eax,255
CALL PB_RGB
MOV dword [v_farbe],eax
Macro:
; farbe.l=RGB2(255,0,255)
MOV dword [v_farbe],16711935
Vielleicht folgen noch andere Funktionen, mal schaun
Verfasst: 11.05.2006 18:51
von Hades
Klasse Tipp! Danke!
Verfasst: 12.05.2006 00:55
von helpy
Das Macro erzeugt im grunde eine Konstante (also einen festen Wert). Die Shift-Befehle werden bereits zur Compile-Zeit ausgeführt ... und müssen daher zur Runtime nicht mehr aufgerufen werden.
Ich schätze mal, dass das Ergebnis anders aussehen wird, wenn Du statt der festen Werte 255,0,255 ... variablen nimmst.
Code: Alles auswählen
Macro RGB2(mpr,mpg,mpb)
(mpr)+(mpg)<<8+(mpb)<<16
EndMacro
r=255
g=0
b=255
k=GetTickCount_()
For a=1 To 100000
For b=1 To 20000
farbe.l=RGB(r,g,b)
Next
Next
p=GetTickCount_()
For a=1 To 100000
For b=1 To 20000
farbe.l=RGB2(r,g,b)
Next
Next
l=GetTickCount_()
MessageRequester("Ergebnis:","Ohne Macro: "+Str(p-k)+Chr(13)+"Mit Macro: "+Str(l-p))
Der Unterschied ist nicht mehr ganz so groß, aber immerhin noch 30% schneller.
cu, helpy
Verfasst: 12.05.2006 07:34
von DrShrek
@Franky,
Sorry, aber Du hast
nicht recht mit Deiner Aussage!
Bezogen auf die PB Funktion RGB() mag Dein Macro RGB2() schneller sein. Aber RGB() ist dafür aber auch vielseitiger (Andere Farbauflösungen).
Hier mal der richtige Vergleich:
Ich habe RGB() ausgetauscht durch 'mpr+mpg<<8+mpb<<16'
Code: Alles auswählen
Macro RGB2(mpr,mpg,mpb)
(mpr)+(mpg)<<8+(mpb)<<16
EndMacro
r=255
g=0
b=255
k=GetTickCount_()
For a=1 To 100000
For b=1 To 20000
farbe.l=mpr+mpg<<8+mpb<<16
Next
Next
p=GetTickCount_()
For a=1 To 100000
For b=1 To 20000
farbe.l=RGB2(r,g,b)
Next
Next
l=GetTickCount_()
MessageRequester("Ergebnis:","Ohne Macro: "+Str(p-k)+Chr(13)+"Mit Macro: "+Str(l-p))
Verfasst: 12.05.2006 08:20
von Deeem2031
@Dr. Shrek:
1. Inwiefern ist die Procedure RGB() vielseitiger?
2. Was willst du mit deinem Test zeigen? Das x = x ist? Also dafür braucht man keinen Test..
Verfasst: 12.05.2006 08:42
von DrShrek
Deeem2031 hat geschrieben:@Dr. Shrek:
1. Inwiefern ist die Procedure RGB() vielseitiger?
Ja habs mir nun mal genauer angesehen...Du hast recht.
Deeem2031 hat geschrieben:@Dr. Shrek:
2. Was willst du mit deinem Test zeigen? Das x = x ist? Also dafür braucht man keinen Test..
Bezogen auf die Überschrift! Es geht hier nicht um Macros generell.
Es geht hier um einen 'schnelleren' Code im Vergleich zur RGB() Funktion.
Nicht um Macros generell.
Es ist ja schon mal deswegen schneller, weil hier kein Funktionsaufruf notwendig ist (oder eben nur deswegen schneller).
Eine Überschrift wie diese wäre besser:
Macro RGB2() min. 3x schneller als RGB()
Nicht vergessen:
Dafür wird aber das spätere Programm etwas grösser!
Verfasst: 12.05.2006 09:13
von Kaeru Gaman
generell finde ich den hinweis gut, dass ein macro eine PB-interne funktion überlagern kann.
man kann bestimmt ne menge functions durch effektivere macros ersetzen, wenn einem die code-größe nicht so wichtig ist.
gerade bei RGB mit festen werten kommt das zum tragen (als konstante eingesetzt), deshalb finde ich das durchaus ein gutes beispiel.
ich könnte mir vorstellen, dass es auch viel bringt, ein Sin()-macro mit argumentumrechnung und array-zugriff zu implementieren.
der knackpunkt dürfte ja wohl sein, dass man in bereits vorhandenen codes eben überlagern kann, anstatt wie blöde durchzueditieren, wie es sein müsste, wenn macros andere namen als funktionen haben müssten.
Verfasst: 14.05.2006 19:14
von hardfalcon
Naja, also in diesem konkreten Fall wärs wohl besser, wenn man Hexadezimalwerte nimmt für feste Farbwerte:
Code: Alles auswählen
$000000 ;schwarz
$FFFFFF ;weiß
$FF0000 ;rot
$FFFF00 ;gelb
$00FF00 ;grün
$00FFFF ;türkis
$0000FF ;blau
$FF00FF ;violett
Verfasst: 15.05.2006 02:52
von ts-soft
hardfalcon hat geschrieben:Naja, also in diesem konkreten Fall wärs wohl besser, wenn man Hexadezimalwerte nimmt für feste Farbwerte:
Code: Alles auswählen
$000000 ;schwarz
$FFFFFF ;weiß
$FF0000 ;rot
$FFFF00 ;gelb
$00FF00 ;grün
$00FFFF ;türkis
$0000FF ;blau
$FF00FF ;violett
Warum ist das besser? Den Compiler interessiert das nicht
Ich würde Konstanten nehmen für feste Farbwerte, und ob denen die Farbe
als Hexwert oder Long zugewiesen wurde ist mir wurscht!
Verfasst: 15.05.2006 10:45
von Kaeru Gaman
> Ich würde Konstanten nehmen für feste Farbwerte
kann man konstanten auch von dem macro zuweisen lassen?
...hab grad kein PB zum testen hier...