Datei Binär Lesen - Typen Casten

tom, mich würde wundern was mehr resourcen braucht. mit fseek an position 6 springen und dann mit fread 2 byte auslesen oder den ganzen scheiß über NSData machen

Ich weiß immer noch nicht, wie du darauf kommst, dass er nur diese zwei Byte will.

Mom, vielleicht habe ich mir verlesen …

Neee, kann ich nicht entnehmen. Wenn er das allerdings wirklich nur so bracuht, verbietet sich jede Performance-Diskussion von vornerein. Dann würde ich einfach den bequemeren weg gehen. Der beginnt in jedem Falle mit NS.

Original von gritsch
tom, mich würde wundern was mehr resourcen braucht. mit fseek an position 6 springen und dann mit fread 2 byte auslesen oder den ganzen &$%§$" über NSData machen

weil ers geschrieben hat - ich hab nix anderes gelesen

Ah, dann habe ich den Plural falsch verstanden.

Original von Tom9811
Dann würde ich einfach den bequemeren weg gehen. Der beginnt in jedem Falle mit NS.

nicht in jedem falle - stell dir vor du gehst mit Carbon durch die ordnerstrukturen und suchst nach bestimmten dateien. Anstatt das alles mit cocoa/Obj-C zu machen verwendet man carbon und schon hat man das ganze um einiges schneller (ich habs ausgetestet ;-))

Hastv du jetzt wieder von bequemer zu schneller gewechselt? Das geht ja hier wie beim Brummkreisel.

Ja, es gibt sicher Fälle. Deinen hast du schon mal gebracht und ich glaube ihn immer noch nicht. Wenn du mir eine Implementierung zeigst, die all das bietet, was Cocoa bietet, fange ich einen Performancevergleich an.

Original von Tom9811
Wenn du mir eine Implementierung zeigst, die all das bietet, was Cocoa bietet, fange ich einen Performancevergleich an.

ich brauch ja nicht das was Cocoa bietet sondern ganz was anderes was ich auf anderem wege 100 mal schneller bekomme (File-types, creator, FSRef, finder-flags und vieles mehr). bei 10 datein merkst du es nicht, aber bei 10.000 schon.

übrigens: das ist net nur schneller sondern braucht auch weniger resourcen. oder glaubst du wenn alles über pfade geht, dann geht es schneller (also die pfade als strings und nicht direkt als FSRef die man dann weiterverwendet bei anderen funktionen)

so bin jetzt weg - feiern hat vorrang

In deinem Spezialfall, in dem begrenzte Funktionalität benötigt ist, hast du dir also etwas schnelleres (und schonenderes) programmiert, als Cocoa bietet.

Schön.

Und was hat das jetzt mit dem OP zu tun? Und mit deiner Antwort darauf? Wollte er exakt das gleiche?

grüße, hab ich mit NSFIleHandle zwar noch nie gemacht aber ich würds so machen:

als erstes einen NSFIleHandle erstellen:

dann überprüfen ob mindestens 2 byte vorhanden sind:

dann data auslesen:

dann die bytes aus NSData rausholen und in eine enstprechende 16-bit-Variable einsetzen:

dann noch abchecken dass die endianess passt und eventuell bytes switchen

das wars auch schon

aja genau, nicht vergessen die datei wieder zu schließen:

Original von gritsch
also wenn ich die ersten 8 byte einer datei brauche (wie ja im thread steht) dann nehm ich bestimmt kein NSData. Das lass ich mir von niemanem einreden! NSFileHandle hingegen gerne

Wer sagt Dir dass NSFileHandle ressourcenfreundlicher als NSData ist?

fopen() und fread() legen ja auch erst mal einen Puffer an und lesen dann (sofern möglich) 1024 Bytes (oder so). Und picken dann die ersten 8 heraus. Da *könnte* NSData mit einem mapped-File ja effizienter vorgehen. Ob es das aber auch tut müßte man mal ausprobieren...

-- hns

Original von gritsch
und eventuell bytes switchen

Hierzu gibt es schöne aber leider sehr wenig bekannte Funktionen in Foundation: NSSwapLittleShortToHost (developer.apple.com/documentat…c/NSSwapLittleShortToHost)

-- hns

Original von hns

Original von gritsch
also wenn ich die ersten 8 byte einer datei brauche (wie ja im thread steht) dann nehm ich bestimmt kein NSData. Das lass ich mir von niemanem einreden! NSFileHandle hingegen gerne

Wer sagt Dir dass NSFileHandle ressourcenfreundlicher als NSData ist?

fopen() und fread() legen ja auch erst mal einen Puffer an und lesen dann (sofern möglich) 1024 Bytes (oder so). Und picken dann die ersten 8 heraus. Da *könnte* NSData mit einem mapped-File ja effizienter vorgehen. Ob es das aber auch tut müßte man mal ausprobieren...

-- hns

hallo hns!
Wo steht denn das mit dem buffer? Das hab ich nicht gewusst und würde mich auch wundern warum fopen nen buffer anlegen sollte.

Original von SaniT
Wie checke ich die Endians? Das hat doch was mit der Codierung zu tun?

du musst wissen welchen dateityp du aufmachst. wie die datei definiert ist (schriften zb sind immer als BE abgespeichert). Es kommt dann aber auch auf den verwendeten datentyp an - du solltest einfach mal das dokument von apple lesen:

developer.apple.com/documentat…ceptual/universal_binary/

dort dann unter swapping bytes

Original von gritsch
Wo steht denn das mit dem buffer? Das hab ich nicht gewusst und würde mich auch wundern warum fopen nen buffer anlegen sollte.

Schonmal den Original Kernighan&Richie gelesen? Da sind Beispielimplementierungen drin.

Ein FILE * ist so ein buffer. Schau Dir mal stdio.h an.

-- hns

Original von SaniT
Wie checke ich die Endians? Das hat doch was mit der Codierung zu tun?

Die Datei ist mit einer Endianness geschrieben und der Prozessor interpretiert Bytefolgen nach einer evtl. anderen.

Wenn beide gleich sind, braucht man nicht Swappen - wenn beide verschieden dann muß man. Deshalb braucht man sich nicht drum kümmern wenn man Dateien nur auf dem gleichen Rechner wieder einliest.

Nun gibts bei Apple beide Prozessorvarianten (68k und PPC sind BigEndian und Intel LittleEndian). Da man den Sourcecode aber davon unabhängig haben will, hat das Apple schon alles in die genannten Funktionen eingebaut. Wenn man es wirklich wissen will, dann kann man da auch ein NSHostByteOrder() abfragen.

Ansonsten verwendet man NSSwapBigIntToHost(). D.h. die Daten aus der Datei sind im Bigendian-Format gespeichert und sollen in das Host-Format. Also z.B. In welcher Byte-Order die Daten allerdings gespeichert sind, hängt von der Dateiformatdefinition ab.

Eine gute erste Vermutung ist: wenn das Format auf Windows/Intel oder Linux erfunden wurde dann ist es LittleEndian. Wenn auf dem mac (68k oder PPC) dann Bigendian. Wenn Daten aus den Internetprotokollen stammen dann gibt es die Network-Byteorder (meist Bigendian).

Notfalls einfach ausprobieren. Es gibt ja nur 2 Möglichkeiten.

Hier ist nochmal alles von anderen erklärt: de.wikipedia.org/wiki/Byte_order

-- hns

Original von hns
Notfalls einfach ausprobieren. Es gibt ja nur 2 Möglichkeiten.

Es gibt (mindestens) drei Möglichkeiten: 1. Immer BE, 2. Immer LE, 3. In der Datei spezifiziert (z.B. TIFF, UTF-16 oder CAF). Im dritten Fall kommst Du mit Ausprobieren nur begrenzt weiter. Besorg' Dir die Spezifikation oder zumindest eine gescheite Dokumentation des Dateiformats, das Du lesen möchtest. Manchmal sind die derart schräg, dass Reverse Engineering zur Hölle wird (ich muss gerade an ID3V2.4 denken - da ist das meiste BE, außer Text als UTF-16. Der ist, abhängig von dem Typfeld, entweder UTF-16BE oder UTF-16 mit BOM - wer kommt bloß auf solche Ideen?)

Original von hns

Original von gritsch
Ein FILE * ist so ein buffer. Schau Dir mal stdio.h an.

Normalerweise ja. Kann man ein- und ausschalten. Ergiebiger als die stdio.h ist "man setvbuf". Ein NSFileHandle ist übrigens typischerweise auch buffered.

Andererseits: Ihr wollt doch nicht ernsthaft anhand der Performance-Unterschiede zwischen FILE und NSFileHandle die API wählen, oder? Beide sind sehr schnell - schnell genug um zu behaupten, dass es bei Performance-Problemen in den meisten Fällen bessere Ansatzpunkte zur Optimierung gibt. Insbesondere ist das wilde Mischen von APIs eine Garantie dafür, dass das Resultat nicht ressourcenschonend wird.