GetHashCode
Hallo,
ich habe mir für mathematische und physikalische Berechnungen zwei Strukturen erstellt, die eine (zur darstellung komplexer Zahlen besteht aus zwei Double-Werten und die andere zur Darstellung von physikalischen Größen besteht aus einem Double-Wert und sechs SByte-Werten.
Dazu jetzt drei Fragen:
Wie viel Speicherplatz verbraten solche Strukturen dann (inklusive Header), die reinen Daten sind ja 28 bzw. 18+6*1 Byte
(mir noch viel wichtiger): Wie kann man für solche Strukturen die GetHashCode-Funktion gut implementieren (meines Wissens hängt davon ja die Effizienz der Datenverarbeitung ab)
Welche Schnittstellen sollte man für die Datenverarbeitung implementieren? (Hab jetzt IEquatable<T>, IComparable<T> und IFormattable)
Im Normalfall müssen Daten an ihrer Größe entsprechenden Speicheradressen ausgerichtet werden. Ein Byte (8Bit) also an Byte-Grenzen (jede Adresse), ein Word (16Bit) an Word-Grenzen (nur gerade Adressen), ein DWord (32Bit) an DWord-Grenzen (durch vier teilbare Adressen) etc.
Der Compiler könnte also deine Strukturen hintereinander im Speicher anordnen, so dass sie 16 respektive 14 Bytes groß sind.
Da du Byte-Werte hast, bringt auch eine Veränderung der Struktur eigentlich nichts, so dass der Compiler dort also nichts optimieren sollte.
Mehr Kontrolle hast du über das Attribut StructLayout.Da du sie als Struct deklarierst, benötigen sie genau so viel Speicher, wie die enthaltenen Daten. Es kann allerdings mehr werden, wenn der Compiler die Reihenfolge der Struktur umsortiert, um wie unter 0. beschrieben zu optimieren.
Ich verwende in solchen Fällen immer die XOR-Verknüpfung der Hashes der involvierten Daten.
Je nach dem, was du brauchst. Ich empfehle noch ICloneable und IConvertible, wenn es Sinn macht.
Das Speicherlayout differiert von 1.1 zu 2.0. In 1.1 macht der JIT das Layout vollautomatisch, die angegebene Reihenfolge wird also optimiert. StructLayout wirkt sich nur auf gemarshallte Strukturen aus.
In 2.0 wirkt sich das StructLayout auch auf managed Strukturen aus. Die Reihenfolge der Definition wird per Default beachtet. Dafür entfällt die Optimierung, also das automatische Packen von Typen die weniger als 4 Bytes lang sind. Wenn man Pech hat, belegt dann wirklich jeder Member mindestens 4 Bytes. Die Optimierung kann man aber via StructLayout und LayoutKind.Auto einschalten.
Unter 2.0 sollte man also durchaus darauf achten, wie man die Member in Strukturen anordnet, bzw. man sollte Auto-Layout verwenden.