der Frager: Wieviel RAM braucht eine Text-Datei

Hi,
wenn ich eine 5 MB große Textdatei mit einem Programm öffne, wieviel Arbeitsspeicher würde die belegen? Was ist mit einer 5 MB großen Binärdatei?

Oder vermutlich kann man das besser ausdrücken, ich wüsste -als Laie- nur nicht wie.

Danke!
der Frager

  1. Hallo,

    wenn ich eine 5 MB große Textdatei mit einem Programm öffne, wieviel Arbeitsspeicher würde die belegen?

    das kann man so nicht beantworten, das kommt *sehr* auf die Arbeitsweise des Programms an.

    Es könnte weniger als 5MB sein, wenn das Programm immer nur den Teil des Textes im Arbeitsspeicher hält, der gerade bearbeitet wird.
    Es könnte genau die Dateigröße sein, wenn das Programm die Textdatei 1:1 in den Arbeitsspeicher kopiert.
    Und es könnte auch erheblich mehr sein, wenn das Programm die Daten in einer Form im Speicher hält, die mehr Speicherplatz braucht, dafür aber günstiger zu verarbeiten ist.

    Was ist mit einer 5 MB großen Binärdatei?

    Kann man ebensowenig sagen.

    Oder vermutlich kann man das besser ausdrücken, ich wüsste -als Laie- nur nicht wie.

    Wenn du uns sagst, worauf du eigentlich hinaus willst, könnten wir der Sache vielleicht näher kommen.

    Ciao,
     Martin

    --
    Zwei Mäuse treiben's miteinander. Sagt der Mäuserich: "Hoffentlich ist nicht wieder alles für die Katz."
    Selfcode: fo:) ch:{ rl:| br:< n4:( ie:| mo:| va:) de:] zu:) fl:{ ss:) ls:µ js:(
    1. Hi Martin,

      Wenn du uns sagst, worauf du eigentlich hinaus willst, könnten wir der Sache vielleicht näher kommen.

      In erster Linie war das nur Interesse. Ich dachte, vielleicht "enfaltet" sich eine Datei im RAM und es gibt eine Fausformel der Berechnung. (z.b. eine 5MB große Textdatei verbraucht 5 mal so viel Platz (=25MB) im RAM.

      Für mich von praktischem Interesse war es, wie sich eine XML-Datei, deren DOM-Baum ich mit einer entsprechenden Funktion lade(z.b. PHPs simple-xml oder einer Python-Entsprechung), im RAM hinsichtlich des verbrauchten Speichers desselben verhält. So könnte man abschätzen, wie groß die Datei auf der Platte sein dürfte, um sie noch zu öffnen, ohne den verfügbaren Speicher zu überschreiten.

      1. Hallo,

        Wenn du uns sagst, worauf du eigentlich hinaus willst, könnten wir der Sache vielleicht näher kommen.
        In erster Linie war das nur Interesse. Ich dachte, vielleicht "enfaltet" sich eine Datei im RAM und es gibt eine Fausformel der Berechnung. (z.b. eine 5MB große Textdatei verbraucht 5 mal so viel Platz (=25MB) im RAM.

        nein, so eine Faustformel gibt es nicht. Als erste Mutmaßung kann man aber davon ausgehen, dass der Speicherbedarf ungefähr gleich der Dateigröße ist. Ungefähr, weil immer auch noch etwas Overhead dazukommt - etwa für programmeigene Variablen.
        Nur wenn das Programm die Daten beim Lesen umcodiert, ändert sich der Speicherbedarf eventuell deutlich. So könnte ein Texteditor beispielsweise so geschrieben sein, dass er intern jedes Zeichen mit 16bit (2 Byte) codiert, während die meisten Textdateien entweder konstant 1 Byte pro Zeichen speichern (z.B. ASCII, oder die ISO-8859-Codierungen), oder je nach Zeichen unterschiedlich viel. UTF-8 belegt beispielsweise je nach Zeichencode ein bis vier Byte für ein Zeichen. Für die Verarbeitung kann es günstig sein, diese Codierung speicherintern umzuschlüsseln.

        Für mich von praktischem Interesse war es, wie sich eine XML-Datei, deren DOM-Baum ich mit einer entsprechenden Funktion lade(z.b. PHPs simple-xml oder einer Python-Entsprechung), im RAM hinsichtlich des verbrauchten Speichers desselben verhält.

        Aufgepasst. Beim Parsen von XML braucht man vor allem Speicherplatz, um den DOM-Baum aufzubauen und abzubilden. Die XML-Datei selbst könnte man sequentiell lesen, so dass man für die "Rohdaten" nicht mehr als ein paar kB als Pufferspeicher braucht - aber das vollständige Lesen in einem Rutsch ist programmtechnisch viel einfacher zu realisieren.
        Wieviel Speicher für den DOM-Baum gebraucht wird, hängt von vielen Faktoren ab, etwa die Anzahl der Knoten und Attribute, die Länge der Element- und Attributbezeichner, und natürlich auch hier wieder die Effizienz des Programms, d.h. wie "verschwenderisch" es mit dem verfügbaren Speicher umgeht.

        So könnte man abschätzen, wie groß die Datei auf der Platte sein dürfte, um sie noch zu öffnen, ohne den verfügbaren Speicher zu überschreiten.

        Sehr gewagt. Beim XML-Parsen würde ich als erste Orientierung annehmen, dass der Speicherbedarf mindestens doppelt so groß ist wie die Dateigröße der XML-Datei.

        So long,
         Martin

        --
        Realität ist eine Illusion, die durch Unterversorgung des Körpers mit Alkohol entstehen kann.
        Selfcode: fo:) ch:{ rl:| br:< n4:( ie:| mo:| va:) de:] zu:) fl:{ ss:) ls:µ js:(
        1. Hallo Martin,

          nein, so eine Faustformel gibt es nicht. Als erste Mutmaßung kann man aber davon ausgehen, dass der Speicherbedarf ungefähr gleich der Dateigröße ist. Ungefähr, weil immer auch noch etwas Overhead dazukommt - etwa für programmeigene Variablen.
          Nur wenn das Programm die Daten beim Lesen umcodiert, ändert sich der Speicherbedarf eventuell deutlich. So könnte ein Texteditor beispielsweise so geschrieben sein, dass er intern jedes Zeichen mit 16bit (2 Byte) codiert, während die meisten Textdateien entweder konstant 1 Byte pro Zeichen speichern (z.B. ASCII, oder die ISO-8859-Codierungen), oder je nach Zeichen unterschiedlich viel. UTF-8 belegt beispielsweise je nach Zeichencode ein bis vier Byte für ein Zeichen. Für die Verarbeitung kann es günstig sein, diese Codierung speicherintern umzuschlüsseln.

          ah, verstehe

          Für mich von praktischem Interesse war es, wie sich eine XML-Datei, deren DOM-Baum ich mit einer entsprechenden Funktion lade(z.b. PHPs simple-xml oder einer Python-Entsprechung), im RAM hinsichtlich des verbrauchten Speichers desselben verhält.

          Aufgepasst. Beim Parsen von XML braucht man vor allem Speicherplatz, um den DOM-Baum aufzubauen und abzubilden. Die XML-Datei selbst könnte man sequentiell lesen, so dass man für die "Rohdaten" nicht mehr als ein paar kB als Pufferspeicher braucht - aber das vollständige Lesen in einem Rutsch ist programmtechnisch viel einfacher zu realisieren.

          Dann ist also sequentielles Lesen von Vorteil?

          Wieviel Speicher für den DOM-Baum gebraucht wird, hängt von vielen Faktoren ab, etwa die Anzahl der Knoten und Attribute, die Länge der Element- und Attributbezeichner, und natürlich auch hier wieder die Effizienz des Programms, d.h. wie "verschwenderisch" es mit dem verfügbaren Speicher umgeht.

          So könnte man abschätzen, wie groß die Datei auf der Platte sein dürfte, um sie noch zu öffnen, ohne den verfügbaren Speicher zu überschreiten.

          Sehr gewagt. Beim XML-Parsen würde ich als erste Orientierung annehmen, dass der Speicherbedarf mindestens doppelt so groß ist wie die Dateigröße der XML-Datei.

          Alles klar. Vielleicht mach ich einfach mal ein paar Tests und sehe mir dann den Speicherbedarf an.

          Danke!

        2. Moin!

          So könnte man abschätzen, wie groß die Datei auf der Platte sein dürfte, um sie noch zu öffnen, ohne den verfügbaren Speicher zu überschreiten.

          Sehr gewagt. Beim XML-Parsen würde ich als erste Orientierung annehmen, dass der Speicherbedarf mindestens doppelt so groß ist wie die Dateigröße der XML-Datei.

          Faktor 2 mit PHP und SimpleXML? Ich würde eher Faktor 10 bis 20 annehmen wollen.

          PHP verbraucht relativ viel Overhead für das Verwalten von Variablen, also zusätzlich zu den reinen Nutzdaten. Das fällt umso stärker ins Gewicht, je geringer die Nutzdaten pro Variable im einzelnen sind. Für das Speichern eines einzelnen Bytes (Zeichen) fällt die gleiche Menge an Verwaltungsinformation an, wie für das Speichern einer Variablen mit 5 Megabyte.

          Eine XML-Datei in ein DOM zu parsen erzeugt jede Menge Variablen. Die ihrerseits in Objekten stecken. Die wieder den Verwaltungsoverhead steigern.

          Wenn man Speicherplatzprobleme bekommt, weil man bislang keine Optimierung in dieser Hinsicht vorgenommen hat (durchaus ein legitimer Ansatz, denn jede Optimierung ist ein Aufwand, der durch irgendeine Anforderung gerechtfertigt sein muss), ist es natürlich relevant, sich durch Messungen erstmal einen Überblick zu verschaffen, um dadurch überhaupt Ansätze für Optimierungen zu ermitteln.

          Das Erhöhen des zugewiesenen Speichers für PHP dürfte dabei allerdings die einfachste Methode sein, kurzfristig zu einer Lösung zu kommen. :)

          - Sven Rautenberg

          1. Hallo,

            Sehr gewagt. Beim XML-Parsen würde ich als erste Orientierung annehmen, dass der Speicherbedarf mindestens doppelt so groß ist wie die Dateigröße der XML-Datei.
            Faktor 2 mit PHP und SimpleXML?

            den eher beiläufigen Hinweis auf "z.b. PHPs simple-xml" habe ich tatsächlich nicht allzu bewusst wahrgenommen; ich bin von einem durchschnittlich effizienten compilierten Programm ausgegangen.

            Ich würde eher Faktor 10 bis 20 annehmen wollen.

            Mit PHP? Ja, mag sein. Ganz so schlecht hätte ich den Wirkungsgrad allerdings doch nicht geschätzt.

            Das Erhöhen des zugewiesenen Speichers für PHP dürfte dabei allerdings die einfachste Methode sein, kurzfristig zu einer Lösung zu kommen. :)

            Solange man die Möglichkeit und die Berechtigung dazu hat. :-)

            Ciao,
             Martin

            --
            Noch Fragen? - Ich weiß es auch nicht.
            Selfcode: fo:) ch:{ rl:| br:< n4:( ie:| mo:| va:) de:] zu:) fl:{ ss:) ls:µ js:(
  2. wenn ich eine 5 MB große Textdatei mit einem Programm öffne, wieviel Arbeitsspeicher würde die belegen? Was ist mit einer 5 MB großen Binärdatei?

    Das kommt darauf an, wie du de Datei öffnest.
    Es gibt Methoden, bei welchen eine zu öffnende Datei praktisch keinen Einfluss auf den aktuellen Ram-Gebrauch eines Prozesses hat.

    Was hingegen teuer ist: Wenn du den Inhalt einer Datei in eine Variable speicherst.

    mfg Beat

    --
    ><o(((°>           ><o(((°>
       <°)))o><                     ><o(((°>o
    Der Valigator leibt diese Fische
    1. Was hingegen teuer ist: Wenn du den Inhalt einer Datei in eine Variable speicherst.

      Da wäre ich mir nicht so sicher:

      In der PHP-Doku zu file_get_contents() ist z.B. folgendes zu lesen:

      "file_get_contents() ist der empfohlene Weg, um den Inhalt einer Datei in einen String zu lesen. Es werden Techniken zur Speicherabbildung genutzt, um die Performance zu erhöhen, falls das Betriebssystem dies unterstützt."

      Was auch immer das bedeutet.

      1. Hallo,

        "file_get_contents() ist der empfohlene Weg, um den Inhalt einer Datei in einen String zu lesen. Es werden Techniken zur Speicherabbildung genutzt, um die Performance zu erhöhen, falls das Betriebssystem dies unterstützt."

        das ändert aber prinzipiell nichts am Speicherbedarf.

        Was auch immer das bedeutet.

        Es bedeutet, dass die gleiche Technik angewendet wird wie beim virtuellen Speicher: Die einzelnen Sektoren der Datei werden direkt in den virtuellen Adressraum der Anwendung "eingeblendet". Es findet also kein Aufruf der Dateisystemfunktionen auf API-Ebene statt, sondern file_get_contents() greift, wenn möglich, direkt aufs Memory Management des OS zurück.

        Ciao,
         Martin

        --
        Die letzten Worte des Hardware-Bastlers:
        Das Netzkabel lass ich wegen der Erdung lieber dran.
        Selfcode: fo:) ch:{ rl:| br:< n4:( ie:| mo:| va:) de:] zu:) fl:{ ss:) ls:µ js:(