nicht angemeldet
你好 hotti,
Selbst, wenn Du eine solche Datei zeilenweise einlesen tust, es muss gesplittet werden, also hast Du in dem Moment die Daten doppelt im RAM, bis das Array fertig ist.
Eine CSV-Datei (was auch nur eine Art der Daten-Serialisierung ist) kann genau so gelesen werden ohne doppelt im Speicher vorzuliegen. Die Art zu lesen und zu parsen hat erstmal nichts mit dem Datenformat zu tun.
Mein Vorschlag geht in Richtung Rohdaten (binary) und Serialisierung, das ist RAM und CPU gefällig, ist sehr performant und es ist dann auch völlig Wurscht, in welcher Codierung die Zeichen vorliegen und ob da ein Komma drin vorkommt, es gibt keine Delimiter, die maskiert werden müssen.
Ein Binär-Format *kann* schneller sein als ein Plaintext-Format, muss es aber nicht. Eine einfache binäre Serialisierung von Daten ist ähnlich schnell wie eine Plaintext-Serialisierung. Auch hier muss die vollständige Datei bis zu der Stelle gelesen werden, die ich haben will. Erst das Einführen von Indizes kann den Zugriff schneller gestalten.
Wenn eine Binärdati eingelesen wird, entfällt auch das splitten,
Das stimmt natürlich nicht. Auch das binäre Format muss geparsed werden.
es werden beim Deserialisieren nur noch bytes gelesen und gleich das Array im RAM gefüllt.
Das gleiche gilt für ein Plaintext-Format. Auch hier werden nur Bytes gelesen und gleich in das Array im RAM gefüllt.
Binäre Datenformate können große Vorteile (und auch große Nachteile) haben und können deutlich schneller zu parsen sein als andere Formate. Aber deine Argumentation ist unsinnig, und das einfache binäre serialisieren macht das lesen von Daten noch nicht schneller. Ich kann mir höchstens vorstellen, dass dein Algorithmus zum parsen von Binär-Daten effektiver ist als der zum Parsen von Plaintext-Daten.
Bei Script-Sprachen musst du natürlich auch darauf achten, dass du das gleiche Interface verwendest: ein in C geschriebener Programmteil ist üblicherweise schneller als ein Script-Pendant (gilt nicht immer, aber oft).
再见,
克里斯蒂安
suit