Seltsame Berechnung mit <sizeOf>

[negaH]

In einem Array[] of RecordXY würde nun der zweite Eintrag nur noch an 2 Bytes Grenze ausgerichtet sein. Dies ist aber nur halb so wild da das auf heutigen CPUs nur 1 Taktzyklus mehr beim Zugriff bedeutet. Die Piplines und der Cache der CPUs sind auf solche Daten optimiert. Der 1 Taktzyklus entsteht nur noch innerhalb der CPU die die 32Bit Daten in 16Bit runterbrechen muß.

Beim Kopieren ist es wiederum irrelevant das man clevererweise mit Move(Source[0], Dest[0], Count * SizeOf(Source[0])); kopieren wird. In diesem Moment behandelt die CPU die kompletten Daten als ein an 4/8 Bytes Grenzen ausgerichteten Datenblock. Das kopieren wäre sogar effizienter mit packed records da viel weniger unnötige Daten kopiert werden müssen.

Nimm immer packed Records kann ich nur sagen, und konzentiere dich darauf deine Algorithmen zu verbessern falls du mehr Speed brauchst. Der Unterschied zwischen packed und unpacked Records würde erst relevant wenn man den Rest des gesammten Codes schonn in handmade Assembler codiert hat, nur dann würde eine Ausrichtung der Daten zum Verhältnis des zeitlichen Programmieraufwandes stehen.

Wenn du wirklich was optimieren willst dann vermeide den Int64 und erhöhe das Word auf Cardinal.
Beim Int64 produziert der Compiler wesentlich inperformanteren Code der sehr oft in die RTL spingen muß, als für Cardinals, und nur beim Zugriff auf 16 Bit oder 8 Bit Daten wird eine 32Bit CPU ausgebremst, somit mache aus dem Word ein Cardinal und alles ist ok.
Das schlimme mit 8/16Bit Daten ist sogar das dieser Flaschenhals innerhalb der CPU die voherigen und nachfolgenden 32Bit CPU Befehle zusätzlich ausbremst, es entshene sogenannte Stalls.

Gruß Hagen