[gelöst] Bits platzschonend speichern
Hallo Kollegen,
Ausgangslage, ich werde ca. 30000 zweidimensionale bool Arrays benötigen, die ungefähr, bzw. max. 40 ^ 2 Werte enthalten, also eine Menge Holz. Ich möchte die Informationen nicht in die DB "kloppen", sondern möchte hier serialisieren, imo geht das schneller. Wenn ich natürlich alle 1er und 0er speichere, dann komme ich schnell auf ein Gigabyte Speicherverbrauch und habe natürlich lange Mapping-Wartezeiten. Jetzt dachte ich, dass ich hier hexadezimale Zahlen speichere (also serialisiere) und dann beim deserialisieren auf die Arrays mappe. Bei den Bits
11111111111111111111 = 20 Stellen würde dann
FFFFF draus werden = 5 Stellen.
Also ein Viertel einsparen. Trotzdem ist das noch sehr viel "Holz". Wie würdet ihr das machen? ggf. ein 64er System einführen oder gar 128er? Oder gibt es hier schon fertige (Komprimierungs) Klassen?
Gruß
Naja, mit der simplen Lauflängenkodierung könntest du eine Menge Speicher sparen.
Hallo mosspower,
aus 20 Bits (11111111111111111111bin) machst du 5 Bytes (FFFFFhex) und hast somit gar nichts gespart.
Oder wolltest du statt des Strings "11111111111111111111" den String "FFFFF" speichern. Dann hättest du zwar was gespart, aber aber die Informationen als String zu speichern ist Quatsch. Du solltest schon binär (als bytes) speichern.
So oder so klingt mir das aber, sorry, nach fehlenden Grundlagen, die wir hier eigentlich voraussetzen.
Serialisieren im .NET Sinne würde ich nicht, sondern die byte-Arrays direkt per BinaryWriter schreiben bzw. mit BinaryReader einlesen.
Kompression der Ausgangsdaten - wie sie jaensen vorschlägt - käme natürlich auch in Betracht.
herbivore
PS: Der Titel "Bits platzschonend speichern" ist eigentlich wirklich witzig. Um ein Bit zu speichern braucht man wieviel Platz? ... genau ... ein Bit. Nicht mehr und nicht weniger. 🙂
@herbivore,
OK, dann bin ich falsch verstanden worden und ich entschuldige mich hundert mal für den falschen Threadtitel. Ich habe gegenwärtig zweidimensionale Boolarrays, die nicht! immer gleich groß sind, mit BinaryFormatter serialisiert. Mit dem BinaryWriter und Reader kann ich doch keine zweidimensionalen Arrays schreiben, die auch noch unterschiedlich lang sind. Woher soll ich dann wissen, wann das eine aufhört und das nächste beginnt? - aber egal, die Größe der Dateien sind absolut identisch, egal ob mit BFormatter oder BWriter. Der BFormatter (wie auch der BWriter) schreibt für jedes Zeichen (also 1 oder 0) einen Eintrag in die Datei (extra noch mal! ausprobiert, damit ich nicht wieder blöd angemacht werde), Deshalb dachte ich, dass ich es eben mit Hexzahlen probiere, mit diesen kann ich 1/4 einsparen und suche hier eben nach noch weiteren Einsparmöglichkeiten.
Hallo mosspower,
zunächst: ich habe gar nichts geschrieben, was anmachend gemeint war.
ich entschuldige mich hundert mal für den falschen Threadtitel.
Der Thread-Titel ist nicht falsch.
Mit dem BinaryWriter und Reader kann ich doch keine zweidimensionalen Arrays schreiben,
Doch das geht. Allerdings kann man nicht einfach das Array übergeben, sondern muss im Zweifel Byte für Byte schreiben.
die auch noch unterschiedlich lang sind. Woher soll ich dann wissen, wann das eine aufhört und das nächste beginnt?
Diese Information müsstest du dann natürlich selbst mit in die Datei schreiben.
Deshalb dachte ich, dass ich es eben mit Hexzahlen probiere, mit diesen kann ich 1/4 einsparen und suche hier eben nach noch weiteren Einsparmöglichkeiten.
Das beste ist eben, das ganze byte-weise zu schreiben. Da du ein Bool-Array hast, müsstest du aber erstmal 8 Bools in ein Byte packen. Das geht mit den Bit-Operatoren von C#: &, |, ~, <<, >>, usw.
herbivore
OK, dann kann ich gleich den BinaryFormatter benutzten, der speichert mir die Arrayinfos mit ab. Sorry, ich habe nicht gewusst, dass Byte-"Zahlen", die ja max 3 Stellen haben können (255) als genau ein Zeichen in der serialisierten Datei wieder auftauchen - OK, von daher ist dies wirklich ein Anfängerfehler. Ich kann nun also ein Achtel einsparen, wenn ich anstatt bool Arrays byte Arrays speicher. Danke für die Aufklärung.