Sinnvoller Dateiaufbau gesucht
-
Hi,
habe eine binäre Datei zur String-Verwaltung. Die sieht in etwa so aus:
[4-byte-integer][asci-string, max. 28 zeichen, evtl. mit 0en aufgefüllt]
Ich nutze C zum Auslesen der Daten (was aber vermutlich keine große Rolle spielt).Nun habe ich gehört, dass einige Prozessoren mit 2er-Potenzen (32) besonders gut rechnen können. Wenn ich jetzt in der Datenbank nur immer die integer lesen möchte, ist dann mein Aufbau sinvvoll? Oder sollte ich den String lieber 32 byte lang machen, damit er nach jedem integer bequem 32 zeichen weiter skippen/seeken kann? Welche Methode ist schneller (und wo findet man entsprechende Literatur?)
Mfg,
voidpointer
-
Hi,
in den heutigen Zeiten wird das nicht mehr die bolle ausmachen, aber wenn schon dahin optimieren, dann so, daß immer ein ganzzahliger Anteil eines Blocks rauskommt. Insofern ist Dein 32 Byte langes Dateielement schon optimal. Da muß immer nur aus einem Block gelesen werden und nie aus zweien. Aber ob der Unterschied heute noch messbar ist???
Gruß Mümmel
-
OK, danke
naja das werden z.T. ziemlich großen Dateien und die müssen sehr häufig durchsucht werden von daher hoffe ich, dass es sich lohnen wird...
-
voidpointer schrieb:
OK, danke
naja das werden z.T. ziemlich großen Dateien und die müssen sehr häufig durchsucht werden von daher hoffe ich, dass es sich lohnen wird...
Wenn du spaeter mal feststellst, dass das wirklich ein Flaschenhals deiner Applikation ist, kannst du's immer noch umschreiben (also kapsel das Daten speichern/einlesen gut
). Aber jetzt Arbeit reinstecken nur weil du drauf spekulierst dass es vielleicht etwas mehr Geschwindigkeit bringt... und selbst wenn: ob dein Programm jetzt nur 0.001 Sekunden statt 0.1 Sekunden fuers Daten durchsuchen braucht, faellt niemandem auf - und das obwohl das eine Geschiwndigkeitssteigerung um ein 100-faches ist! Eine der wichtigsten Programmierregeln ist "premature optimization is the root of all evil"
-
Geht ja ums Prinzip
Habe mich nur wirklich gefragt, ob der Compiler schneller ist, wenn er 32 bit anstatt z.B. 28 vorwärts seeken soll (wenn es sich um den gleichen Block handelt)...
-
lies die daten einfach blockweise ein, völlig unabhängig davon, wie sie nun in der datei vorliegen. das "parsen" kann dann im speicher stattfinden. dateizugriffe sind um mehr als faktor 1000 langsamer als operationen im ram. es macht schon sinn, sich eine sinnvolle struktur für die daten auszudenken, aber um bytepadding muss man sich nun wirklich keine gedanken machen.
-
Völlig egal, du solltest nur nicht byteweise auslesen, das wird langsam bei Großen Dateien. Mein Tipp, schnapp dir ein XML parser, dann musst du dir um sowas keine Gedanken mehr machen.
-
voidpointer schrieb:
Geht ja ums Prinzip
Habe mich nur wirklich gefragt, ob der Compiler schneller ist, wenn er 32 bit anstatt z.B. 28 vorwärts seeken soll (wenn es sich um den gleichen Block handelt)...
Ich bezweifle, dass das einen auch noch so kleinen Unterschied macht (du meinst Bytes, bei Bits sähe es anders, da man noch shiften müsste). Das (Geschwindigkeits-)Problem wird hier eher das Lesen der Daten von der Festplatte sein. Wie schon vorgeschlagen, solltest du nicht für jeden Datensatz einmal read/seek aufrufen, sondern einen großen Block von Daten einlesen und dann im Speicher verarbeiten.
-
Danke, dann werde ich das Probieren!
Gibt es eine Möglichkeit, über Header-Dateien eines Systems die Block-Größe zu erfahren?
-
voidpointer schrieb:
Gibt es eine Möglichkeit, über Header-Dateien eines Systems die Block-Größe zu erfahren?
wenn du die block größe des datenträgers meinst: nein. aber mit "in blöcken lesen" ist gemeint, dass du immer jeweils eine bestimmte anzahl an bytes auf einmal einließt. typisch sind z.b. 8KB pro lesevorgang.