Hallo,
meines Wissens gab / gibt es die Theorie, dass es im MSTS Arbeitsspeicher sparen würde, wenn man "unnötige" Zeilenumbrüche und Leerzeichen aus den Dateien entfernen würde.
Ich kann der Theorie nicht ganz folgen und bin auch eher ein Verfechter der "Lesbarkeit".
Warum ich der Theorie nicht folgen kann? Nun ja - der MSTS liest Dateien grundsätzlich nicht komplett am Stück ein, um sie anschließend zu verarbeiten.
Ich habe bisher keine Ausnahme bei der Verarbeitung der Dateien im MSTS gefunden. Es betrifft also *.eng-Dateien genauso wie die großen Textur-Dateien (*.ace). Dabei ist es auch völlig unerheblich, in welchem Format (ungepackt, komprimiert, DXT usw.) die Dateien vorliegen. Der MSTS geht beim Einlesen von Dateien von der Festplatte immer wie folgt vor:
- Öffnen der benötigten Datei, d.h. Anforderung eines Handles (eine Art Zugriffsnummer, die vom Betriebssystem vergeben wird).
- Der MSTS reserviert einen Puffer-Speicher im Arbeitsspeicher von genau 16384 Byte (oder 16 KByte) Größe.
- Einlesen der ersten 2 Byte der Datei in den Puffer-Speicher. Der MSTS bestimmt an Hand der ersten beiden Bytes, ob es sich um eine Unicode-Datei handelt.
- Abhängig vom Ergebnis der Unicode-Prüfung liest der MSTS die nächsten 14 oder 32 Bytes in den Puffer-Speicher ein, wobei die bereits gelesenen 2 Byte im Puffer überschrieben werden. Der MSTS erhält somit den sog. Header (beginnend mit der vielleicht bekannten Zeichenfolge "SIMISA"). Somit "weiß" der MSTS anschließend, in welchem seiner Formate die Datei vorliegt und wie diese zu interpretieren ist.
- Der MSTS lässt sich anschließend die Größe der Datei vom Betriebssystem geben, um am Ende nicht über das Dateiende hinaus Daten anzufordern.
- Nun liest der MSTS maximal 16384 Byte der Datei in den Puffer-Speicher und überschreibt dabei die bisherigen Daten im Puffer-Speicher. Der Inhalt des Puffer-Speichers wird nun vom MSTS verarbeitet. Er füllt seine internen Datenstrukturen. Sollte eine weitere Datei benötigt werden (zum Beispiel eine Shape-Datei oder Textur), so wird diese auf die gleiche Weise geöffnet und komplett abgearbeitet (mit eigenem 16 KByte-Puffer-Speicher), wie die aktuelle Datei. Anschließend geht es in der aktuellen Datei weiter.
- Sollte das Dateiende noch nicht erreicht worden sein, geht es wieder zurück zu Schritt 6.
- Am Ende gibt der MSTS das Handle wieder frei.
- Falls der Puffer-Speicher nicht direkt für die nächste Datei benötigt wird, wird auch der Puffer-Speicher wieder freigegeben. Der Algorithmus, der bestimmt, ob der Puffer-Speicher wiederverwendet werden kann, scheint nicht ganz perfekt zu sein. Es kann vorkommen, dass der Puffer-Speicher erhalten bleibt und ungenutzt reserviert ist. Dieses "Speicherleck" schlägt zu, wenn man immer wieder eine Aufgabe startet und beendet, ohne den MSTS zwischendurch zu beenden.
Fazit:
Der MSTS benutzt für jede geöffnete Datei einen Puffer-Speicher von 16 KByte Größe - unabhängig davon, wie groß die Datei tatsächlich ist. Geöffnet wird eine Datei nur bei Anforderung und wird anschließend gleich wieder geschlossen. Wenn man die Abhängigkeiten der Dateien untereinander betrachtet, dürften nie mehr als vier oder fünf Dateien gleichzeitig geöffnet sein. Das wären dann maximal 64 bis 80 KByte reservierter Arbeitsspeicher für das Lesen von Dateien im MSTS. Das ist verschwindend wenig.
Diese Technik des häppchenweisen "Lesens" von Dateien ist übrigens keine Spezialität des MSTS, sondern gehört eigentlich zur guten Schule der Anwendungsentwicklung, um die System-Ressourcen zu schonen.
Auch das Entpacken von komprimierten Daten läuft kontinuierlich als Stream, also während des Lese-Vorgangs.
Ob das Betriebssystem die Datei bei Anforderung in einen vom System verwalteten Cache-Speicher lädt, kann der MSTS nicht beeinflussen. Dieser Cache gehört auch nicht zum Speicherbereich der Anwendung (also des MSTS). Zudem ist die Nutzung des Cache-Speichers abhängig von dem zur Verfügung stehenden Arbeitsspeicher im System.
Also - lieber lesbar bleiben...