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.
:
Bearbeitet durch User
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.
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.