spieleprogrammierer.de - Forum und Wiki zur Spieleprogrammierung und Spieleentwicklung

Ähm, in der Theorie mag das vielleicht Auswirkungen haben, nur zum Einen bestehen diese nur zur Compilezeit, und wie viele Zehntausende Includes hast du denn, dass du meinst dass diese 2 Bytes mehr das Parsen spürbar verlangsamen würden? Man soll ja nicht am falschen (Datei-)Ende sparen ; )
(ansonsten wird das anscheinend eh willkürlich benutzt, ich sehe selten .hpp Dateien, auch wenn es C++-Programme sind)

Zitat von »m3xx«

Das heißt, das dieses ".hpp" also nur in der compilezeit spürbar mit atomuhren messbar ist und nicht mehr im späteren Programm?

Hab das mal für dich korrigiert

Das auf jeden Fall. Im Programm gibt es so etwas wie Dateien nicht mehr. Ja nicht einmal so etwas wie C++ gibt es da noch.

Also ob man jetzt etwas .h oder .hpp nennt hat Speichermässig nur etwas im Filesystem einen Einfluss und Laufzeitmässig im parsen des Codes. Allerdings ist das parsing keine sehr aufwändige Sache, sondern eher andere Teile des Compilers (Analyse, Optimierung etc.).

Hier musste ich echt lachen
Warum nennst du deine Dateien nicht gleich einfach nur "a", "b", "c" usw., wenn es dir auf jedes Byte ankommt?

@m3xx
Du musst halt lernen abschätzen zu können was wo gebraucht wird und welche Abhängigkeiten sich so nachziehen. Dass das schwer ist, vor allem am Anfang, ist klar. Aber wenn du dir mal die grundlegenden Schritte überlegst was passiert, wenn ein Programm kompiliert, dann hättest du da auch selbst drauf kommen können.

Grundsätzlich gilt ja eigentlich: Nichts nimmt dir Performance weg, was du programmierst. Das gilt solange bis du mit Messungen das Gegenteil beweisen kannst.
Klar hat alles einen Einfluss, aber das meiste, was man an Toolsets braucht und wie man programmiert ist eigentlich egal. Nur ein sehr kleiner Teil spielen am Ende eine Rolle und die ohne Messungen zu lokalisieren ist extrem schwer.

Schonmal von der 80-20-Regel gehört? Bei den meisten Programmen wird 20% des Codes in 80% der Zeit ausgeführt. Was bedeutet das? Wenn du später wirklich Performanceprobleme haben solltest, musst du erstmal nur 20% deines Codes kräftig optimieren. Der Rest ist fast egal.

Wenn jemand auf deinem Stand ein Spiel schreibt, das starke Performanceprobleme hat, hast er einen groben Fehler gemacht und z.B. alle Images in einem Frame geladen, in einer Schleife viel Speicher angefordert ohne ihn freizugeben oder einfach zu viele Spielobjekte erzeugt.

Damit will ich nur bestätigen was Drakon sagt. Du brauchst dir um die Performance keine großen Gedanken zu machen bis du Probleme damit hast. Das heißt aber nicht, dass du verschwenderisch mit Resourcen umgehen darfst. Mach es nur nicht komplizierter um (scheinbar) mehr performance rauszuholen.