Hallo zusammen,
zwischen Eagle 5.x und Eagle 6.x hat sich ja bekanntlich das Dateiformat
von einem Binärformat in ein XML-Format geändert. Letzteres belegt
naturgemäß deutlich mehr Festplattenplatz, was von vielen Benutzern sehr
negativ angesehen wird.
Was mich interessiert: Hat schon jemand mal den verbrauchen
Speicherplatz verglichen/getestet für
- gepackte Dateien?
- im Repository eines Versionsverwaltungssystem hinterlegte Dateien?
Insbesondere bei Bastelprojekten verbringen die meisten Dateien den
Großteil ihrer Lebensdauer im gepackten/archivierten Zustand; deswegen
mein Interesse an diesem Aspekt.
Ich kann das auch selbst testen. Nur falls es schon einmal jemand
gemacht hat, spare ich mir die Zeit Aufsetzen einer virtuellen Maschine
für diesen Test...
Viele Grüße
W.T.
Auch wenn ich persönlich kein Freund von XML bin (bloated, komplex zu
parsen, viel zu viel Overhead), so bin ich noch viel weniger Freund von
Binärformaten.
Im speziellen bei Eagle freut sich meine Versionskontrolle (Subversion)
natürlich sehr über die ASCII-Files, Diffs werden viel kleiner, und vor
allem sind die Diffs auch "human readable". SO kann ich sowohl bei Libs
als auch bei normalen Schematics/Boards sehr schnell nachprüfen, was
sich geändert hat, speziell wenn man wieder mal im Eifer des gefechts 15
Änderungen gleichzeitig gemacht hat.
Dateigröße sollte in Zeiten von terrabyte-Festplatten kein Thema mehr
sein...
Walter Tarpan schrieb:> Hallo zusammen,> zwischen Eagle 5.x und Eagle 6.x hat sich ja bekanntlich das Dateiformat> von einem Binärformat in ein XML-Format geändert. Letzteres belegt> naturgemäß deutlich mehr Festplattenplatz, was von vielen Benutzern sehr> negativ angesehen wird.
Quellen? Eigentlich jucken die paar Bytes überhaupt niemanden. XML
Formate sind ja nichts neues. Viele Hersteller schwenkten von Binär auf
XML, inkl. MS seit Office 2007.
Das bisschen Speicherplatz bringt hingegen auch für den Nutzer Vorteile,
da man nun Dateien einfach lesen und auch verändern kann. Auch öffnet es
Möglichkeiten für Drittsoftware, solche Dateien zu verändern (Skripte,
Editore usw.). SVN und Co. freuen sich natürlich auch, weil die Diffs
kleiner werden.
Die Unkerei gegen das XML-Format wegen ein bisschen mehr Speicher ist
total lachhaft.
genau das selbe kleine Schaltplan, mit IEC-625 Buchse, USB Buchse, 2x
DIP20, 1x TQFP100, 1x PLCC44, 1x SO8, 45x meistens 0603 Hühnerfutter:
- Eagle 5.x (binary) ~ 330kB
- Eagle 5.x (binary) zipped ~ 77kB
- Eagle 6.1 (XML) ~ 960kB
- Eagle 6.1 (XML) zipped ~ 85kB
- Altium (Protel 4 binary) ~ 83kB
- Altium (Protel 4 binary) zipped ~ 11kB
- Altium (Protel 5 binary) ~ 460kB
- Altium (Protel 5 binary) zipped ~ 41kB
- Altium (Protel 5 ACSII) ~ 461kB
- Altium (Protel 5 ASCII) zipped ~ 46kB
Sicherlich sind die XML/ASCII formate einfach (von Hand) zu editieren,
falls man es wirklich irgendwann ran muss. Dies musste ich in letzten
Jahren nur einmal machen, um eine "kaputte" Eagle 6.x zu besitigen
(damit ich ins Altium importieren kann).
Michael Reinelt schrieb:>> Dateigröße sollte in Zeiten von terrabyte-Festplatten kein Thema mehr> sein...
ehm, 1TB voll mit zipped Protel 4 sind 87TB im Eagle 6.1 XML Format,
beim redundanten System sind dies gleich 3TB vs 261TB :\
Natürlich benutze ich kein Protel 4 mehr, längst alles konvertiert,
dies war aber gleich 4x bis 6x mehr (Netto, also ohne RAID) HDD Platz.
Bleibt man beim zipped Eagle 5.x v. zipped Eagle 6.x dann sind es nur
1.2TB vs 1TB und 20% mehr sind wirklich (fast) kein Thema mehr.
Thomas R. schrieb:> genau das selbe kleine Schaltplan, mit IEC-625 Buchse, USB Buchse, 2x> DIP20, 1x TQFP100, 1x PLCC44, 1x SO8, 45x meistens 0603 Hühnerfutter:>> - Eagle 5.x (binary) ~ 330kB> - Eagle 5.x (binary) zipped ~ 77kB>> - Eagle 6.1 (XML) ~ 960kB> - Eagle 6.1 (XML) zipped ~ 85kB
Hallo Thomas,
Super! Danke für die sauber aufgeschlüsselten Informationen! Mit dem
Super-Komprimierer Subversion (ich habe keine Ahnung wie, aber SVN
kriegt die Datenbank immer kleiner als eine ZIP- oder RAR-Komprimierung
einer einzelnen sich darin befindendenden PDF-Datei) sollte der Overhead
Binary vs. XML ja wirklich nicht ins Gewicht fallen.
cyblord ---- schrieb:> [...]>> Quellen? Eigentlich jucken die paar Bytes überhaupt niemanden.>> [...]
Wenn man sich die Dateien im Text-Editor/HEX Editor anschaut, brauche
ich keine Quelle. OK, ich kann nicht beweisen, daß das XML wirklich
XML-konform ist. Aber für die Komprimierbarkeit sollte das kein
Unterschied sein.
Michael Reinelt schrieb:> Dateigröße sollte in Zeiten von terrabyte-Festplatten kein Thema mehr> sein...
Ist es für mich aber: Gerade CAD-Sachen sind sehr oft dupliziert, landen
in Emails, Versionsverwaltungen und Websites und werden veschickt. Oft
mehrfach. Das läppert sich.
Im Gegensatz zu den "riesigen" Filmen und Musik, von denen man nur eine
Version hat und die auch nicht so oft verschickt werden.
Michael Reinelt schrieb:> Im speziellen bei Eagle freut sich meine Versionskontrolle (Subversion)> natürlich sehr über die ASCII-Files, Diffs werden viel kleiner, und vor> allem sind die Diffs auch "human readable". SO kann ich sowohl bei Libs> als auch bei normalen Schematics/Boards sehr schnell nachprüfen, was> sich geändert hat, speziell wenn man wieder mal im Eifer des gefechts 15> Änderungen gleichzeitig gemacht hat.
Das ist natürlich ein Vorteil, den ich auch gerne mitnehme.
Viele Grüße
W.T.
Alles unter 10 MB ist doch Peanuts, wir fummeln hier nicht mehr mit
Disketten rum.
Und der Vergleich mit Altium ist lustig, das müllt so heftig rum im
Projekt-Verzeichnis das es ziemlich egal ist in welchem Format die
eigentlichen Daten gespeichert sind.
Interessiert am Ende aber auch nicht wirklich.
Walter Tarpan schrieb:> zwischen Eagle 5.x und Eagle 6.x hat sich ja bekanntlich das Dateiformat> von einem Binärformat in ein XML-Format geändert. Letzteres belegt> naturgemäß deutlich mehr Festplattenplatz, was von vielen Benutzern sehr> negativ angesehen wird.
Da sich der Informationsgehalt der Dateien eigentlich nicht geändert
hat, sollte das nach einer vernünftigen Datenkompression keine Rolle
spielen - und tut es wie obige Zahlen zeigen, auch kaum.
