Binær vs. ASCII-filstørrelse

Hvis din eneste bekymring er filstørrelse, så vil du have binære filer. For et illustrativt eksempel kan vi antage, at du skriver 1 flydende punktnummer med dobbelt præcision til en fil. Lad os antage, at filsystemet kan håndtere dette perfekt og holde filen, overskrifter og polstring er alle 0.

For en binær fil, ville dette nummer tage den nøjagtige størrelse af antallet i RAM, eller 8 byte.

I ASCII-format vil det indeholde:

• 16 cifre i basen
• 1 periode i decimalen
• 1 tegn for at afgrænse eksponenten
• 1 tegn for eksponentens tegn
• 2-3 tegn for eksponenten

Forudsat det bruger kun 1 byte til et tegn, det vil sige 22 byte til at indeholde det samme antal. Dette tæller ikke de tegn, der kræves for at skelne mellem tal (normalt mindst 1). Derfor vil filstørrelsen til ASCII-format være ca. 3 gange større.

Du kan handle i filstørrelse for præcisionen i de lagrede filer (kun holde 5-6 cifre i basen), men det afhænger af hvad du bruger dem til. Den største fordel ved ASCII er at debugge eller producere læsbare data.

Kommentarer

• Også vigtig på det videnskabelige område er langsigtet arkivering og pålidelig deling, hvorfor ASCII CSV på trods af dets ineffektivitet er så udbredt og anbefales (PDF) .
• Et andet nyttigt punkt er, at selvom ASCII CSV-kodning ikke er ‘ t meget effektiv, ved hjælp af et filkomprimeringsværktøj (som zip, gzip osv.) på din ASCI fil vil typisk bringe filstørrelsen ned til noget, der ligner størrelsen på en binær fil.
• Vær forsigtig, fordi nogle input- / outputbiblioteker ikke er ‘ t forsigtige nok for at få bit til bit reproducerbarhed, når du udsender IEEE Double Precision-tal i ASCII og derefter læser dem tilbage. Efter min erfaring er det undertiden nødvendigt at bruge 17 eller 18 decimaler for sikkerheden.
• Med hensyn til horchler ‘ s kommentar: Jeg ‘ er sikker på, at velbrugte, standardiserede åbne binære formater som HDF5 vil eksistere i lang tid. At ‘ er det, jeg ‘ personligt anbefaler.
• + Jeg holder mig til binær, når det er muligt, for nøjagtighed, kompakthed, ro i sindet og (især) hastighed. Så hvis jeg har brug for yderligere kompakthed, kan jeg zip den. Hvis jeg har brug for at være i stand til visuelt at læse indholdet, kan jeg skrive et lille program til det. På den anden side, hvis det ‘ er vigtigere at være visuel og let overføres til tilfældige programmer som Excel, R osv., Så er CSV vejen at gå.

I praksis har du sjældent brug for data i visualiseringsfiler, der er mere nøjagtige end f.eks. 3 gyldige I så fald er ASCII – måske overraskende – ofte mere kompakt end binær form. Hvis du tænker på arkivering, vil bzip-ing af disse ASCII-filer sandsynligvis give de mindste filer, du kan få.

Når det er sagt, læser Paraview VTU-format, som har en komprimeret binær form (XML-baseret, men dataene først libz-komprimeres og derefter uu-kodet igen for at give ASCII-tekst). På typiske filer sparer dette en faktor på 4-10. For store filer er dette bestemt den rigtige vej.

Kommentarer

• Jeg stemte op for kontrasten til det andet svar. Jeg har ikke ‘ hverken en stærk mening, men der er ‘ et godt punkt at have her.
• Alternativt kan du eksplicit nulstille de lave bits og komprimere den binære.
• Wow, det ville kræve en del bit-fiddling. Eller er der funktioner, der gør det? (Bortset fra casting til at flyde og tilbage til dobbelt.)

tl; dr – gem filer i utf8 . Hvis det er i tabelform, skal du bruge TAB-adskilte værdier.

Det forekommer mig, at de rigtige muligheder er:

1. utf8 tekst ( ikke ASCII . Vi er ikke alle engelsktalende)
2. binær

ASAICT den eneste reelle fordel ved binære filer er ydeevne. Det er meget hurtigere at indlæse en hukommelsesdump i hukommelsen end at generere tekst på vej ud eller analysere den på vej ind.

f.eks. https://www.cfd-online.com/Forums/openfoam/136983-binary-gives-significant-performance-advantage-mesh-solve.html

Eller her: https://auth0.com/blog/beating-json-performance-with-protobuf/ (Dette er ikke videnskabeligt og diskuterer den samlede præstation, hvor de store forskelle er mængden af transmitterede data og parseringstiden i en sag, der er forudindtaget i retning af tekstdata. )

Chancerne for, at et binært filformat korrekt understøtter unicode-tekst, er dårlige, så Hvis du er interesseret i dataintegritet, skal du ikke bruge binær . Har du også hørt om endianproblemer? Forskellige binære repræsentationer af underskrevne heltal og floats?

Tekstrepræsentationer på -100000 og -1e + 6 ændrer ikke værdi afhængigt på din CPU (i hvert fald i utf-8 og ASCII).

Chancerne for at et program, der forstår en binær fil, stadig vil forstå det eller stadig køre 50 år fra nu er ukendt, sandsynligvis ikke godt . Hvis du holder af lang levetid, skal du ikke bruge binær .

Det er ofte svært at læse binære data fra et andet program, så Hvis du er interesseret i interoperabilitet, skal du ikke bruge binær .

Bortset fra: CSV er et forfærdeligt filformat . Det er simpelt, men alligevel dårligt defineret og kræver en stateful parser. Brug ikke CSV. Hvis det er nødvendigt, skal du bruge TSV. Det er enklere, men bedre defineret og trivielt at analysere.

https://chriswarrick.com/blog/2017/04/07/csv-is-not-a-standard/

https://www.cloudbakers.com/blog/everything-you-didnt-want-to-have-to-know-about-csv

Hvis du er bekymret for størrelsen, komprimer .

(Jeg kom her på udkig efter undersøgelser af den relative størrelseseffektivitet af komprimeret binær repræsentation vs. komprimeret tekst. Jeg har stadig ikke fundet gode oplysninger bortset fra denne undersøgelse af VRML, men jeg er ikke engang sikker på, om det er en sammenligning af base64-kodet binær vs. binær. https://www.cs.unc.edu/~isenburg/papers/is-bcraf-03.pdf .)