Code beschleunigen, verbessern...

Übersicht

BlitzBasic

Beginners-Corner

Gehe zu Seite 1, 2 Weiter

	nyron Betreff: Code beschleunigen, verbessern...	Fr, März 04, 2005 22:40 Antworten mit Zitat
Hallo! Ich habe mal ein paar fragen dazu, wie man den Code beschleunigen bzw. verbessern kann, sodass das Programm besser und schneller läuft: 1. Machen lange Variablen das Pragramm vielleicht minimal langsamer??: Beispiel: dieshieristdasergebnis_einersinnlosenaufgabe = dieselangevariable_ist_nur_eintest + dieselangevariable_ist_auchnur_eintest oder a= x+y gibt es beim ersten Beispiel einen Zeitverlust? //---------------------------------------------- 2. Werden Kommentare und Leerzeichen wirklich vom Compiler ignoriert, sodass diese eigentlich gar nicht da sind? //---------------------------------------------- 3. Verlangsamen Funktionen das Programm? Beispiel: Repeat cls Laufen() Springen() Attacke() Gegner() Kollision() Pause() flip Forever Nehmen wir einfach mal an, dieses Spiel würde ruckeln. Könnte man das ruckeln dann vielleicht beheben oder minimieren, wenn man anstatt den Funktionen sofort den Code einfügt? (In diesem Beispiel dienen die Funktionen nicht zum übergeben von Parametern sondern nur zur besseren Übersicht) //---------------------------------------------- Habt ihr vielleicht sonstnoch andere Tipps auf Lager??

nyron

Betreff: Code beschleunigen, verbessern...

Fr, März 04, 2005 22:40
Antworten mit Zitat

Hallo!

Ich habe mal ein paar fragen dazu, wie man den Code beschleunigen bzw. verbessern kann, sodass das Programm besser und schneller läuft:

1. Machen lange Variablen das Pragramm vielleicht minimal langsamer??:
Beispiel:

dieshieristdasergebnis_einersinnlosenaufgabe =
dieselangevariable_ist_nur_eintest + dieselangevariable_ist_auchnur_eintest

oder

a= x+y

gibt es beim ersten Beispiel einen Zeitverlust?

//----------------------------------------------

2. Werden Kommentare und Leerzeichen wirklich vom Compiler ignoriert, sodass diese eigentlich gar nicht da sind?

//----------------------------------------------

3. Verlangsamen Funktionen das Programm?
Beispiel:

Repeat
cls
Laufen()
Springen()
Attacke()
Gegner()
Kollision()
Pause()
flip
Forever

Nehmen wir einfach mal an, dieses Spiel würde ruckeln.
Könnte man das ruckeln dann vielleicht beheben oder minimieren, wenn man anstatt den Funktionen sofort den Code einfügt?
(In diesem Beispiel dienen die Funktionen nicht zum übergeben von Parametern sondern nur zur besseren Übersicht)

//----------------------------------------------

Habt ihr vielleicht sonstnoch andere Tipps auf Lager??

	Seoman	Fr, März 04, 2005 22:50 Antworten mit Zitat
1. Theoretisch schon, hat aber in der Praxis keine Bedeutung. Versuche lieber, überflüssige Befehle wegzulassen... 2. Ja! Natürlich kann man wieder behaupten "Es muss ausgelesen werden, dass da etwas ignoriert werden muss", spielt aber ebenfalls kaum eine Rolle. 3. Genau das selbe, ich würde aber Functions immer beibehalten, weil du dich sonst im Code nicht mehr zurechtfindest. Tipps: Vermeide langsame Befehle, Versuche, alles mit möglichst wenig Code umzusetzen (Bsp.: UDP (Internet-Protokoll) Lasse einzelne PC's möglichst wenig versenden. Benutze "Arbeitsteilung", damit nicht ein PC alles alleine errechnet, ...) mfg Seoman
In Australien... Projekte sind zur Zeit wieder eingefroren und auf Designlevel zurueckgestuft... Generalueberholungen notwendig

Seoman

Fr, März 04, 2005 22:50
Antworten mit Zitat

1. Theoretisch schon, hat aber in der Praxis keine Bedeutung. Versuche lieber, überflüssige Befehle wegzulassen...

2. Ja! Natürlich kann man wieder behaupten "Es muss ausgelesen werden, dass da etwas ignoriert werden muss", spielt aber ebenfalls kaum eine Rolle.

3. Genau das selbe, ich würde aber Functions immer beibehalten, weil du dich sonst im Code nicht mehr zurechtfindest.

Tipps:
Vermeide langsame Befehle, Versuche, alles mit möglichst wenig Code umzusetzen (Bsp.: UDP (Internet-Protokoll) Lasse einzelne PC's möglichst wenig versenden. Benutze "Arbeitsteilung", damit nicht ein PC alles alleine errechnet, ...)

mfg
Seoman

In Australien...

Projekte sind zur Zeit wieder eingefroren und auf Designlevel zurueckgestuft... Generalueberholungen notwendig Wink

	Hubsi	Fr, März 04, 2005 23:22 Antworten mit Zitat
1. Spielt keine Rolle, ausser beim Tippaufwand Die Exe arbeitet nicht direkt mit Variablen, sondern Speicheradressen, wenn ich nicht irre (bin) 2. Hast Du schonmal Kommentare oder Leerzeilen in einer Exe entdeckt? 3. Funktionen sind eine feine Sache, ich persönlich würde sie aber in der von Dir gezeigten Weise nie einsetzen. Jeder Funktionsaufruf kostet etwas Zeit, wenn auch nicht wirklich viel. Den Code also so zu verschachteln halte ich für keine gute Idee. Generell speichere ich Rückgabewerte von Funktionen die ich mehr als einmal pro Hauptschleifendurchlauf brauche in Variablen ab, wie z.B. MilliSecs(), KeyDown(), MouseHit() oder MouseX/Y() etc., da es einfach schneller ist den Wert einer Variable zu lesen als jedesmal die Funktion aufs neue aufzurufen. Suco-X hat zum Thema Speed mal ein Tut geschrieben, wenn ich mich recht entsinne. Das ist sicher auch recht praktisch
Den ganzen Doag im Bett umanandflagga und iaz daherkema und meine Hendl`n fressn...

Hubsi

Fr, März 04, 2005 23:22
Antworten mit Zitat

1. Spielt keine Rolle, ausser beim Tippaufwand Very Happy

Die Exe arbeitet nicht direkt mit Variablen, sondern Speicheradressen, wenn ich nicht irre (bin)

2. Hast Du schonmal Kommentare oder Leerzeilen in einer Exe entdeckt? Wink

3. Funktionen sind eine feine Sache, ich persönlich würde sie aber in der von Dir gezeigten Weise nie einsetzen. Jeder Funktionsaufruf kostet etwas Zeit, wenn auch nicht wirklich viel. Den Code also so zu verschachteln halte ich für keine gute Idee.

Generell speichere ich Rückgabewerte von Funktionen die ich mehr als einmal pro Hauptschleifendurchlauf brauche in Variablen ab, wie z.B. MilliSecs(), KeyDown(), MouseHit() oder MouseX/Y() etc., da es einfach schneller ist den Wert einer Variable zu lesen als jedesmal die Funktion aufs neue aufzurufen. Suco-X hat zum Thema Speed mal ein Tut geschrieben, wenn ich mich recht entsinne. Das ist sicher auch recht praktisch Wink

Den ganzen Doag im Bett umanandflagga und iaz daherkema und meine Hendl`n fressn...

	Apocalyptic	Fr, März 04, 2005 23:35 Antworten mit Zitat
Hubsi hat Folgendes geschrieben: Suco-X hat zum Thema Speed mal ein Tut geschrieben, wenn ich mich recht entsinne. Das ist sicher auch recht praktisch Du meinst sicherlich TheShadow, oder? Das Tutorial gibts auf blitzbase.de, es ist aber auch bei der Onlinehilfe mit dabei.
Suum cuique [ www.ffs-net.de.vu ] [ Raycaster ]

Apocalyptic

Fr, März 04, 2005 23:35
Antworten mit Zitat

Hubsi hat Folgendes geschrieben:

Suco-X hat zum Thema Speed mal ein Tut geschrieben, wenn ich mich recht entsinne. Das ist sicher auch recht praktisch Wink

Du meinst sicherlich TheShadow, oder? Das Tutorial gibts auf blitzbase.de, es ist aber auch bei der Onlinehilfe mit dabei.

Suum cuique

[ www.ffs-net.de.vu ] [ Raycaster ]

	konstantin	Fr, März 04, 2005 23:36 Antworten mit Zitat
das meißte wird eh vom präcompiler richtig geschustert. kommentare etc werden von ihm ausradiert und die includes gebastelt, usw.

konstantin

Fr, März 04, 2005 23:36
Antworten mit Zitat

das meißte wird eh vom präcompiler richtig geschustert. kommentare etc werden von ihm ausradiert und die includes gebastelt, usw.

	BIG BUG	Fr, März 04, 2005 23:42 Antworten mit Zitat
Den Code wie im Beispiel mit Funktionen zu strukturieren, bringt in der Praxis keinen Geschwindigkeitsverlust. Funktionen solltest Du höchstens in den Innerloops meiden(diese Funktionen also mehrere 100 mal PRO Frame aufgerufen würden). Aber diese Stellen zu analysieren und optimieren kannst Du auch am Schluss machen. BlitzBasic ist vermutlich sogar so schlau, konstante Berechnungen bereits während dem kompilieren zu optimieren. z.B. x = y + 10 / 2 x = y + 5 Beide Ausdrücke würden dann in der Executable so wie der untere aussehen.
B3D-Exporter für Cinema4D!(V1.4) MD2-Exporter für Cinema4D!(final)

BIG BUG

Fr, März 04, 2005 23:42
Antworten mit Zitat

Den Code wie im Beispiel mit Funktionen zu strukturieren, bringt in der Praxis keinen Geschwindigkeitsverlust. Funktionen solltest Du höchstens in den Innerloops meiden(diese Funktionen also mehrere 100 mal PRO Frame aufgerufen würden). Aber diese Stellen zu analysieren und optimieren kannst Du auch am Schluss machen.

BlitzBasic ist vermutlich sogar so schlau, konstante Berechnungen bereits während dem kompilieren zu optimieren.
z.B.
x = y + 10 / 2
x = y + 5
Beide Ausdrücke würden dann in der Executable so wie der untere aussehen.

B3D-Exporter für Cinema4D!(V1.4)
MD2-Exporter für Cinema4D!(final)

	Hubsi	Sa, März 05, 2005 0:21 Antworten mit Zitat
Apocalyptic hat Folgendes geschrieben: Hubsi hat Folgendes geschrieben: Suco-X hat zum Thema Speed mal ein Tut geschrieben, wenn ich mich recht entsinne. Das ist sicher auch recht praktisch Du meinst sicherlich TheShadow, oder? Das Tutorial gibts auf blitzbase.de, es ist aber auch bei der Onlinehilfe mit dabei. Ups, ja hab das mit "Aufbau und Strukturierung" durcheinander gehauen
Den ganzen Doag im Bett umanandflagga und iaz daherkema und meine Hendl`n fressn...

Hubsi

Sa, März 05, 2005 0:21
Antworten mit Zitat

Apocalyptic hat Folgendes geschrieben:

Hubsi hat Folgendes geschrieben:

Suco-X hat zum Thema Speed mal ein Tut geschrieben, wenn ich mich recht entsinne. Das ist sicher auch recht praktisch Wink

Du meinst sicherlich TheShadow, oder? Das Tutorial gibts auf blitzbase.de, es ist aber auch bei der Onlinehilfe mit dabei.

Ups, ja hab das mit "Aufbau und Strukturierung" durcheinander gehauen Embarassed

Den ganzen Doag im Bett umanandflagga und iaz daherkema und meine Hendl`n fressn...

	stfighter01	Sa, März 05, 2005 0:26 Antworten mit Zitat
hier ist schon fast alles gesagt, aber das muss ich nochmal anbringen. verhaspelt euch nicht mit der optimierung. macht den code lieber leserlich, strukturiert ihn schön und spart !nicht! and funktionen. diese sollten schon sinnvoll sein, aber opfert dafür nicht flexibilität. das schlimmste verbrechen ist es ein programmstück 2mal zu schreiben, nur um einen funktionsaufruf zu ersparen. 95% od. mehr geht üblicherweise beim rendern u. zeichnen drauf. wers nicht glaubt kann ja mal die zeit messen. mfg stfighter
Denken hilft!

stfighter01

Sa, März 05, 2005 0:26
Antworten mit Zitat

hier ist schon fast alles gesagt, aber das muss ich nochmal anbringen.

verhaspelt euch nicht mit der optimierung.
macht den code lieber leserlich, strukturiert ihn schön und spart !nicht! and funktionen. diese sollten schon sinnvoll sein, aber opfert dafür nicht flexibilität. das schlimmste verbrechen ist es ein programmstück 2mal zu schreiben, nur um einen funktionsaufruf zu ersparen.
95% od. mehr geht üblicherweise beim rendern u. zeichnen drauf.
wers nicht glaubt kann ja mal die zeit messen.

mfg stfighter

Denken hilft!

	Spikespine	Sa, März 05, 2005 11:22 Antworten mit Zitat
Ich muss stfighter Recht geben! Spike
Athlon 64 3700+ \| 1024 MB RAM \| GeForce 7900 GT \| Blitz2D, Blitz3D, BlitzPlus, BlitzMax

Spikespine

Sa, März 05, 2005 11:22
Antworten mit Zitat

Ich muss stfighter Recht geben!

Spike

Athlon 64 3700+ | 1024 MB RAM | GeForce 7900 GT | Blitz2D, Blitz3D, BlitzPlus, BlitzMax

	NetPad	Sa, März 05, 2005 12:55 Antworten mit Zitat
es gibt schon einige sachen, die man beachten sollte. zum einen ist das villeicht, dass man hintergrundbilder so komprimiert, dass das ergebnis immer noch passabel ist, jedoch die grösse der datei sinkt. es gibt nichts schlimmeres als spiele die von hobbyprogrammierer erstellt wurden, die längere ladezeiten haben als grosse spiele wie half-life. zum code optimieren: da kann ich nicht viel sagen, da schon das wichtigste erzählt wurde. es gibt einige fehler, die das optische ergebnis nicht beinflussen, jedoch die berechnungszeit erhöhen: bsp: Code: [AUSKLAPPEN] [EINKLAPPEN] for i=0 to 1000 feld(i)=10i felder_gesetzt=true next da eigentlich gemeint war: Code:* [AUSKLAPPEN] [EINKLAPPEN] for i=0 to 1000 feld(i)=10*i next felder_gesetzt=true das resultat ist dasselbe, aber man kann rechenzeit sparen. auch nützlich ist, wenn man sich die vorgehensweise mehrere male durch den kopf gehen lässt. oft findet man mit der zeit alternativen, die deutlich weniger rechnen als die erst beste möglichkeit grs NP

NetPad

Sa, März 05, 2005 12:55
Antworten mit Zitat

es gibt schon einige sachen, die man beachten sollte.
zum einen ist das villeicht, dass man hintergrundbilder so komprimiert, dass das ergebnis immer noch passabel ist, jedoch die grösse der datei sinkt.

es gibt nichts schlimmeres als spiele die von hobbyprogrammierer erstellt wurden, die längere ladezeiten haben als grosse spiele wie half-life.

zum code optimieren:
da kann ich nicht viel sagen, da schon das wichtigste erzählt wurde. es gibt einige fehler, die das optische ergebnis nicht beinflussen, jedoch die berechnungszeit erhöhen:
bsp:

Code: [AUSKLAPPEN]

for i=0 to 1000
feld(i)=10*i
felder_gesetzt=true
next

da eigentlich gemeint war:
Code: [AUSKLAPPEN]

for i=0 to 1000
feld(i)=10*i
next
felder_gesetzt=true

das resultat ist dasselbe, aber man kann rechenzeit sparen.

auch nützlich ist, wenn man sich die vorgehensweise mehrere male durch den kopf gehen lässt. oft findet man mit der zeit alternativen, die deutlich weniger rechnen als die erst beste möglichkeit

grs NP

	FBI-blitz	Sa, März 05, 2005 12:58 Antworten mit Zitat
Die größe von Bildern macht doch bei der Ladezeit überhaupt nic aus, glaube ich! Eben die Spielgröße!
Computer 1: AMD Athlon64 3500+ \| nVidia GF 7900GT \| 1024 MB DDR-RAM \| ASUS A8N-SLI Preimium \| 250 GB SATA 2 \|\| WindowsXP \| Blitz3D \| Blitz+ Computer 2: AMD AthlonXP 2400+ \| ATI Radeon 9500 \| 512 MB DDR-RAM \| MSI K7N2 \| 80 GB IDE \| 160 GB IDE \|\| WindowsXP \| Blitz3D \| Blitz+ Computer 3: Intel Pentium MMX \| onBoard-Grafik \| 32 MB RAM \| 1 GB IDE \|\| Windows 98 SE \| Blitz+

FBI-blitz

Sa, März 05, 2005 12:58
Antworten mit Zitat

Die größe von Bildern macht doch bei der Ladezeit überhaupt nic aus, glaube ich! Eben die Spielgröße!

Computer 1: AMD Athlon64 3500+ | nVidia GF 7900GT | 1024 MB DDR-RAM | ASUS A8N-SLI Preimium | 250 GB SATA 2 || WindowsXP | Blitz3D | Blitz+
Computer 2: AMD AthlonXP 2400+ | ATI Radeon 9500 | 512 MB DDR-RAM | MSI K7N2 | 80 GB IDE | 160 GB IDE || WindowsXP | Blitz3D | Blitz+
Computer 3: Intel Pentium MMX | onBoard-Grafik | 32 MB RAM | 1 GB IDE || Windows 98 SE | Blitz+

	BladeRunner Moderator	Sa, März 05, 2005 13:31 Antworten mit Zitat
Zitat: zum einen ist das villeicht, dass man hintergrundbilder so komprimiert, dass das ergebnis immer noch passabel ist, jedoch die grösse der datei sinkt. Jetzt lachen wir mal. Du wirst allenfalls die Downloadzeit damit senken falls das Proggie nit eh als Zip angeboten wird. Dafür muss das Bild jedoch zur Laufzeit beim einladen erst dekomprimiert werden- der Ladevorgang als solches dauert also länger. Intern werden alle Graphiken unkomprimiert in der GraKa abgelegt. Mit deinem Vorschlag erreichst Du also genau das was du vermeiden willst.
Zu Diensten, Bürger. Intel T2300, 2.5GB DDR 533, Mobility Radeon X1600 Win XP Home SP3 Intel T8400, 4GB DDR3, Nvidia GF9700M GTS Win 7/64 B3D BMax MaxGUI Stolzer Gewinner des BAC#48, #52 & #92

BladeRunner

Moderator

Sa, März 05, 2005 13:31
Antworten mit Zitat

Zitat:

zum einen ist das villeicht, dass man hintergrundbilder so komprimiert, dass das ergebnis immer noch passabel ist, jedoch die grösse der datei sinkt.

Jetzt lachen wir mal.
Du wirst allenfalls die Downloadzeit damit senken falls das Proggie nit eh als Zip angeboten wird.
Dafür muss das Bild jedoch zur Laufzeit beim einladen erst dekomprimiert werden- der Ladevorgang als solches dauert also länger.
Intern werden alle Graphiken unkomprimiert in der GraKa abgelegt.

Mit deinem Vorschlag erreichst Du also genau das was du vermeiden willst.

Zu Diensten, Bürger.
Intel T2300, 2.5GB DDR 533, Mobility Radeon X1600 Win XP Home SP3
Intel T8400, 4GB DDR3, Nvidia GF9700M GTS Win 7/64
B3D BMax MaxGUI
Stolzer Gewinner des BAC#48, #52 & #92

	NetPad	Sa, März 05, 2005 13:32 Antworten mit Zitat
ich glaube schon das das eine rolle spielt! ist sicherlich ein unterschied, ob du nun 10ein 5MB bild lädst, oder 10ein 2MB bild.

NetPad

Sa, März 05, 2005 13:32
Antworten mit Zitat

ich glaube schon das das eine rolle spielt!
ist sicherlich ein unterschied, ob du nun 10*ein 5MB bild lädst, oder 10*ein 2MB bild.

	Spikespine	Sa, März 05, 2005 13:33 Antworten mit Zitat
Zitat: ich glaube schon das das eine rolle spielt! ist sicherlich ein unterschied, ob du nun 10ein 5MB bild lädst, oder 10ein 2MB bild. glaube ich nicht! Mal ausprobieren... edit: ok, getestet. Die beiden Dateien wurden ungefähr gleich schnell geladen, wobei die eine 3kb und die andere 256 kb groß war, bei gleichen abmessungen.
Athlon 64 3700+ \| 1024 MB RAM \| GeForce 7900 GT \| Blitz2D, Blitz3D, BlitzPlus, BlitzMax

Spikespine

Sa, März 05, 2005 13:33
Antworten mit Zitat

Zitat:

ich glaube schon das das eine rolle spielt!
ist sicherlich ein unterschied, ob du nun 10*ein 5MB bild lädst, oder 10*ein 2MB bild.

glaube ich nicht! Mal ausprobieren...

edit: ok, getestet. Die beiden Dateien wurden ungefähr gleich schnell geladen, wobei die eine 3kb und die andere 256 kb groß war, bei gleichen abmessungen.

Athlon 64 3700+ | 1024 MB RAM | GeForce 7900 GT | Blitz2D, Blitz3D, BlitzPlus, BlitzMax

	BladeRunner Moderator	Sa, März 05, 2005 13:42 Antworten mit Zitat
Ich will mal eine kleine Analogie benutzen: Wenn du Dir bei Ikea nen Schrank kaufst ist er in seine Einzelteile zerlegt (komprimiert). Der Transport nach Hause (Download, von mir aus auch einladen von der Festplatte) geht so schneller von statten. Allerdings musst Du den Schrank zuhause erst mühsam aufbauen (dekomprimieren) damit Du ihn nutzen kannst. Die Grafikkarte kann mit dem komprimierten Bild auch nicht arbeiten, sie benötigt das Rohformat. Und da das Aufbauen des Schrankes (dekomprimieren) einiges an Zeit und Aufwand braucht ist die insgesamt benötigte Zeit größer. Man muss halt abwägen was man will. Für Normalautobesitzer ist der zerlegte Schrank wunderbar. Wer jedoch die Spedition bemüht oder einen Kleintransporter sein eigen nennt wird lieber auf fertige (dekomprimierte) Artikel zurückgreifen.
Zu Diensten, Bürger. Intel T2300, 2.5GB DDR 533, Mobility Radeon X1600 Win XP Home SP3 Intel T8400, 4GB DDR3, Nvidia GF9700M GTS Win 7/64 B3D BMax MaxGUI Stolzer Gewinner des BAC#48, #52 & #92

BladeRunner

Moderator

Sa, März 05, 2005 13:42
Antworten mit Zitat

Ich will mal eine kleine Analogie benutzen:
Wenn du Dir bei Ikea nen Schrank kaufst ist er in seine Einzelteile zerlegt (komprimiert).
Der Transport nach Hause (Download, von mir aus auch einladen von der Festplatte) geht so schneller von statten.
Allerdings musst Du den Schrank zuhause erst mühsam aufbauen (dekomprimieren) damit Du ihn nutzen kannst. Die Grafikkarte kann mit dem komprimierten Bild auch nicht arbeiten, sie benötigt das Rohformat.
Und da das Aufbauen des Schrankes (dekomprimieren) einiges an Zeit und Aufwand braucht ist die insgesamt benötigte Zeit größer.

Man muss halt abwägen was man will. Für Normalautobesitzer ist der zerlegte Schrank wunderbar.
Wer jedoch die Spedition bemüht oder einen Kleintransporter sein eigen nennt wird lieber auf fertige (dekomprimierte) Artikel zurückgreifen.

Zu Diensten, Bürger.
Intel T2300, 2.5GB DDR 533, Mobility Radeon X1600 Win XP Home SP3
Intel T8400, 4GB DDR3, Nvidia GF9700M GTS Win 7/64
B3D BMax MaxGUI
Stolzer Gewinner des BAC#48, #52 & #92

	NetPad	Sa, März 05, 2005 13:54 Antworten mit Zitat
Spikespine hat Folgendes geschrieben: ok, getestet. Die beiden Dateien wurden ungefähr gleich schnell geladen, wobei die eine 3kb und die andere 256 kb groß war, bei gleichen abmessungen. tut mit leid. dann habe ich etwas falsches behauptet. ich teste das dann bei mir auch einmal. @bladerunner: lustiges beispiel leider kaufe ich keine schränke bei IKEA hilft aber trotzdem weiter grs NP

NetPad

Sa, März 05, 2005 13:54
Antworten mit Zitat

Spikespine hat Folgendes geschrieben:

ok, getestet. Die beiden Dateien wurden ungefähr gleich schnell geladen, wobei die eine 3kb und die andere 256 kb groß war, bei gleichen abmessungen.

tut mit leid. dann habe ich etwas falsches behauptet. ich teste das dann bei mir auch einmal.

@bladerunner:
lustiges beispiel Very Happy

leider kaufe ich keine schränke bei IKEA Wink

hilft aber trotzdem weiter

grs NP

	FBI-blitz	Sa, März 05, 2005 14:03 Antworten mit Zitat
Ja! Und Blitz wandelt doc heh alles in bmp um!
Computer 1: AMD Athlon64 3500+ \| nVidia GF 7900GT \| 1024 MB DDR-RAM \| ASUS A8N-SLI Preimium \| 250 GB SATA 2 \|\| WindowsXP \| Blitz3D \| Blitz+ Computer 2: AMD AthlonXP 2400+ \| ATI Radeon 9500 \| 512 MB DDR-RAM \| MSI K7N2 \| 80 GB IDE \| 160 GB IDE \|\| WindowsXP \| Blitz3D \| Blitz+ Computer 3: Intel Pentium MMX \| onBoard-Grafik \| 32 MB RAM \| 1 GB IDE \|\| Windows 98 SE \| Blitz+

FBI-blitz

Sa, März 05, 2005 14:03
Antworten mit Zitat

Ja! Und Blitz wandelt doc heh alles in bmp um!

	Nox	Sa, März 05, 2005 14:21 Antworten mit Zitat
So, ich schreib auch nochmal was zum Verständnis (wer mal Assembler geschrieben hat weiß, dass Variablenlängen und Funktionsaufrufe garnicht bis kaum di eGeschwindigkeit beeinträchtigen). Wie bereits gesagt wurde, sind Variablen nichts anderes als Pointer zu späteren Speicheradressen im Programmstack. Du kannst sie also benennen, wie du willst. Kommentare werden ignoriert. Was verbraucht ein Funktionsaufruf denn maximal an Ressourcen? Bei einem Aufruf (CALL) wird die Adresse der CALL-Instruction auf den Stack geschoben (Nanosekunde? ). In der Funktion selbst werden vielleicht noch einige Register des Prozessors auf den Stack gesichert und gegen Ende wieder zurück in die Register geschrieben. Das passiert aber so dermaßen schnell, dass sowas NIEMALS einen Geschwindigkeitsnachteil mit sich führen würde.

Nox

Sa, März 05, 2005 14:21
Antworten mit Zitat

So, ich schreib auch nochmal was zum Verständnis (wer mal Assembler geschrieben hat weiß, dass Variablenlängen und Funktionsaufrufe garnicht bis kaum di eGeschwindigkeit beeinträchtigen).

Wie bereits gesagt wurde, sind Variablen nichts anderes als Pointer zu späteren Speicheradressen im Programmstack. Du kannst sie also benennen, wie du willst.

Kommentare werden ignoriert.

Was verbraucht ein Funktionsaufruf denn maximal an Ressourcen? Bei einem Aufruf (CALL) wird die Adresse der CALL-Instruction auf den Stack geschoben (Nanosekunde? Smile

). In der Funktion selbst werden vielleicht noch einige Register des Prozessors auf den Stack gesichert und gegen Ende wieder zurück in die Register geschrieben. Das passiert aber so dermaßen schnell, dass sowas NIEMALS einen Geschwindigkeitsnachteil mit sich führen würde.

	denial	Sa, März 05, 2005 20:56 Antworten mit Zitat
@Nox zum Thema Assembler: Längere Variablennamen nehmen nicht nur kaum sondern definitiv KEINE längere Rechenzeit in Anspruch. Da, wie du gesagt hast, das Ergebniss letztendlich sowieso eine Adresse ist. AFAIK ist BlitzBasic aber mehr eine VM als ein echter ASM-Compiler, zumindest trifft das auf die "alte" 2D/3D Version zu. Vielleicht irre ich mich auch, ich hab das mal gelesen.
http://lydian.cone-grafix.de <- aktuelles Projekt: 32-Bit Maschinensprachen Compiler

denial

Sa, März 05, 2005 20:56
Antworten mit Zitat

@Nox zum Thema Assembler:
Längere Variablennamen nehmen nicht nur kaum sondern definitiv KEINE längere Rechenzeit in Anspruch. Da, wie du gesagt hast, das Ergebniss letztendlich sowieso eine Adresse ist.

AFAIK ist BlitzBasic aber mehr eine VM als ein echter ASM-Compiler, zumindest trifft das auf die "alte" 2D/3D Version zu. Vielleicht irre ich mich auch, ich hab das mal gelesen. Smile

http://lydian.cone-grafix.de <- aktuelles Projekt: 32-Bit Maschinensprachen Compiler

	stfighter01	Sa, März 05, 2005 22:24 Antworten mit Zitat
@FBI-blitz der überhaupt nicht verstanden hat worums geht. bmp, jpg, png... sind dateiformate. und Blitz wandelt kein format in irgendein anderes um. selbst eine bmp-datei ist kein 1:1 abbild des images im speicher (wenn du das andeuten wolltest). eine BMP ist ein fertiger kühlschrank, aber immer noch eingepackt in karton. mfg stfighter
Denken hilft!

stfighter01

Sa, März 05, 2005 22:24
Antworten mit Zitat

@FBI-blitz der überhaupt nicht verstanden hat worums geht.
bmp, jpg, png... sind dateiformate.
und Blitz wandelt kein format in irgendein anderes um.
selbst eine bmp-datei ist kein 1:1 abbild des images im speicher (wenn du das andeuten wolltest).

eine BMP ist ein fertiger kühlschrank, aber immer noch eingepackt in karton. Wink

mfg stfighter

Denken hilft!

Gehe zu Seite 1, 2 Weiter

Übersicht

BlitzBasic

Beginners-Corner

Nach Oben

BlitzBasic Portal

Code beschleunigen, verbessern...

Betreff: Code beschleunigen, verbessern...