TDK hat geschrieben:Da beim Komprimieren allerdings tausende Einzeldateien komprimiert werden, spielt die Zeit schon eine Rolle. Die Content Creator reagieren sonst immer so gereizt, wenn alles so lange dauert...
Dann komprimier es halt nicht während der Entwicklungsphase, sondern nur vorm Ausliefern; dann schrumpft der Zeitaufwand gegen Null.
TDK hat geschrieben:Ansonsten werden diese auch teilweise während des Simulationslaufes nachgeladen, ab und zu mehrmals. Und da ist eine schnelle Leserate, und vor allem auch weniger Festplattenknistern, von Vorteil. Und die CPU benötige ich nebenbei auch noch.
Dann komprimier am besten garnicht – dann werden ab dem zweiten Lauf weder Festplatte noch CPU
überhaupt benötigt.
TDK hat geschrieben:Jedes MB zählt, da das gesamte Programm mit den verschiedenen Welten viele Gigabyte in Anspruch nehmen wird.
Bei Snappy kannst du mir nicht erzählen, dass „jedes Byte zählt“. Wenn die Welten sechs oder sieben GiB in Anspruch nehmen, dann sollen sie das halt. (Ich werte das auch einfach mal als
die Daten kommen von der Festplatte eines PCs).
Afaik nutzen selbst RAD Game Tools Kompression nur noch auf Konsolen, weil der Windows Page Cache auf dem PC
alles wegrockt. Und mit
wegrocken meine ich an eigenen Beobachtungen: 12.000 Dateien in einer Drittelsekunde in den Speicher holen; 4 GiB unkomprimierte Texturen 100× schneller einblenden als die zlib-komprimierten Varianten – mit CPU-Unkosten gegen Null.
Ich habe bei meinem derzeitigen Projekt auch die Wahl, es mit einem komprimierten Paket aus zu starten oder mit einem unkomprimierten Verzeichnis (erwähnte 12k Dateien) – und ich nehme
immer das Verzeichnis, weil mich die Wartezeiten sonst in den Wahnsinn treiben.
Komprimiert werden sollte nur für die Auslieferung via Installer. Davor und danach hat alles unkomprimiert zu sein.