Seltsame Berechnung mit <sizeOf>

[Luckie]

Zitat:

Zitat von Dannyboy

Moin Luckie,
logisch erscheint mir eher, dass int64 (8 Bytes) + word (2 bytes) insgesamt 10 Bytes ergeben.

Warum das nicht so ist, wurde dir oben erklärt. Und wenn du das gelesen hast, weißt du auch wie du den Record deklarieren musst, damit er dir nur die 10 Byte in die Datei schreibt.

[Dannyboy]

Zitat:

Zitat von Luckie

Warum das nicht so ist, wurde dir oben erklärt. Und wenn du das gelesen hast, weißt du auch wie du den Record deklarieren musst, damit er dir nur die 10 Byte in die Datei schreibt.

... allerdings unter Performanceverlust, den ich, wie oben bereits erwähnt, nicht eingehen möchte. Mir scheint, die sequentielle Lösung (ohne Record) ist am Besten geeignet, oder? :gruebel:

[Chewie]

Jetzt mach dir nicht ins Hemd wg. den angeblichen Performance-Einbußen. Das Ansteuern des richtigen Sektors der Festplatte dauert 100mal länger als der Zugriff auf dein Record.

[Luckie]

Merkst du den unterschied zwischen 1000 und 5000 CPU Taktzyklen? Also ich nicht. :gruebel:

[Dannyboy]

Zitat:

Zitat von Luckie

Merkst du den unterschied zwischen 1000 und 5000 CPU Taktzyklen? Also ich nicht. :gruebel:

Um mich verstehen zu können, muss ich das ganze Projekt, aus dem das Problem hervorgeht, etwas näher beschreiben. Es geht nämlich nicht nur um das einmalige Lesen/Schreiben von 10 (bzw. 16) Bytes.
Listen up:
Es geht um einen Leveleditor, der unendlich (durch den Speicherplatz der Festplatte begrenzt) große Levels haben kann. Daher kommt auch dieser Thread von mir. Ich habe die logische Physik bereits fertig programmiert und getestet, ergo geht es nun um die Performance. Dieser Editor verwendet eine temporäre Auslagerungsdatei, da man nicht eine unendliche Menge an Informationen im RAM speichern kann. Nehmen wir mal an, jemand erstellt sich mit Hilfe des Editors eine Levelmap, die mehrere 100 MB einnimmt (an einem solchen Level würde man sein Leben lang zocken :love: ), dann muss in dieser Datei andauernd gelesen und geschrieben werden. Es werden immer <6000 * Höhe des Levels)> aktuelle Bytes aus der Datei geladen und wenn ich in dieser Datei (und für das Datenarray) generell <packed records> verwende, dann gehe ich davon aus (ich hab's bisher noch nicht testen können), dass ich zu sehr an Performance einbußen muss. Ich möchte noch mal erwähnen, dass eine solche Datei theoretisch riesig sein kann und ich habe dieses Projekt mit einer temporären Auslagerungsdatei realisiert, damit die Levels so riesig sein können. Andernfalls hätte ich das ganze Level auch komplett in ein RAM-fressendes, riesiges Array klatschen können.

Das Problem, das sich ergibt, ist, dass ich auf keinen Fall Performace verlieren möchte, aber die Level-Map-Dateien sollen auf keinen Fall größer werden als nötig.
Bin gern' für Vorschläge bereit. :zwinker:

[NicoDE]

Dann solltest Du eher darüber nachdenken, ob eine Weite von Low(Int64) bis High(Int64) überhaupt Sinn macht...

[Dannyboy]

Zitat:

Zitat von NicoDE

Dann solltest Du eher darüber nachdenken, ob eine Weite von Low(Int64) bis High(Int64) überhaupt Sinn macht...

Du meinst, weil die Levelbreite nicht größer als High(int64) sein kann?
Das sind schon einige GB, oder?
Damit lassen sich immerhin (2^64 DIV 2) Bytes (nur positiver Bereich) darstellen,
das sind 9.223.372.036.854.775.808 Bytes. Das langt mir oder meinst Du
etwas anderes? :gruebel:

[NicoDE]

Zitat:

Zitat von Dannyboy

Du meinst, weil die Levelbreite nicht größer als High(int64) sein kann?

Ich meine, dass negative Weiten keinen Sinn ergeben (spart ein Bit ;)) und, meiner bescheidenen Meinung nach, ein Word ausreichend ist.
(falls notwendig halt mit Multiplikator - sprich, man kann nur Weiten in 1024-er Schritten verwenden, etc pp)

[Dannyboy]

Zitat:

Zitat von NicoDE

Zitat:

Zitat von Dannyboy

Du meinst, weil die Levelbreite nicht größer als High(int64) sein kann?

Ich meine, dass negative Weiten keinen Sinn ergeben (spart ein Bit ;)) und, meiner bescheidenen Meinung nach, ein Word ausreichend ist.
(falls notwendig halt mit Multiplikator - sprich, man kann nur Weiten in 1024-er Schritten verwenden, etc pp)

Der int64-Wert steht ja nur ein einziges Mal in der Datei (im Header) und
die breite des Levels ist immer positiv.
Die Dateilänge auf 65536 (Word) zu begrenzen langt nicht.
Ein Level der Höhe 100 Einheiten hätte somit dann eine maximale Breite von 109 Einheiten.
Das ist viel zu wenig.

[NicoDE]

Zitat:

Zitat von Dannyboy

Der int64-Wert steht ja nur ein einziges Mal in der Datei (im Header)

Dann verstehe ich das Performance-'Problem' nicht, da es nur beim Zugriff auf nicht ausgerichtete Member und/oder nicht ausgerichtete (packed) Arrays auftritt...