Nun, anstatt zu erraten, habe ich die Antwort. Hier ist das Testprogramm:
%Vor%Und das ist die gemessene Ausgabe:
%Vor%JSON kam nach 1 Iteration immer nur ein kleines bisschen schneller raus. Nach 1000 Iterationen gab es keinen Unterschied. Nach 10000 Iterationen war XML deutlich schneller.
An diesem Punkt kann ich nicht erklären, warum JSON einzeln schneller sein würde, aber XML wäre schneller, wenn es wiederholt wird. Möglicherweise aufgrund von Caching oder etwas Phantasie in der Bibliothek. Sie können sehen, dass der JsonSerializer linear skaliert wurde, indem Sie die Iterationen in einer Größenordnung von 10 erhöhen. Die XmlSerializer hat sich anders verhalten, seine Leistung wurde nicht linear skaliert.
Ich habe das mehrmals wiederholt und immer die gleichen Ergebnisse erzielt.
Die Lektion ist also, wenn Sie nur ein einzelnes Objekt analysieren, dann wird JSON etwas besser sein. Wenn Sie jedoch Objekte wiederholt analysieren, wird XML möglicherweise besser. Obwohl ich nicht getestet habe, was passieren würde, wenn sich die Objektwerte mit jeder Iteration ändern würden, könnte das einen Unterschied machen.
Beachten Sie auch, dass ich hier die native Runtime.Serialization-Bibliothek verwende. Andere Bibliotheken werden wahrscheinlich zu anderen Ergebnissen führen.
Edit: Ich habe das gerade probiert, während ich jedes Mal, wenn die Strings aufgerufen werden, ein neues Guid und ein zufälliges Int erzeuge. Es machte keinen Unterschied zu den einzelnen oder 10000 Iterationstests. Aber für 1000 Iterationen war JSON etwa 1 ms schneller. Es sieht so aus, als ob der XML-Serializer die Werte wirklich zwischenspeichert.
Wenn ich in einer .NET-Anwendung nach einer Konfiguration suche, erwarte ich eine XML-Datei namens MyApp.exe.config.
Beim Prinzip der geringsten Überraschung würde ich die XML-Serialisierung über JSON bevorzugen. Es gibt einen zusätzlichen Vorteil, dass die XML-formatierte Konfiguration angepasst werden kann, um mit dem zu arbeiten Konfigurations-API Beide haben ansonsten die gleiche Art von Unterstützung: plattformunabhängig, anständige Parser, textbasiert, etc.
Leistung ist nur ein Problem, wenn es zu einem Problem wird. Ich bin ein Fan davon, mögliche Probleme zu identifizieren, bevor ich sie code, aber das ist in der Regel auf Leistungsprobleme, die durch Architekturentscheidungen eingeführt werden. So etwas, klein und ziemlich eigenständig, wird nicht schwierig zu ändern sein, wenn es sich beim Profiling als problematisch erweist.
Json kann von Menschen manchmal weniger lesbar sein als xml, aber die Größe der von json erzeugten Datei ist kleiner. Also, wenn Sie die Datei über das Netzwerk senden müssen, ist Json die bessere Wahl, oder wenn Sie in der Lage sein möchten, es zu lesen, ist XML besser. Eine weitere gute Sache ist, dass Sie in .NET 4 das dynamische Schlüsselwort haben, und Sie können Ihre Json direkt in ein C # -Objekt konvertieren.
Meiner Meinung nach hängt alles davon ab, was Sie tun müssen und wie Sie es implementieren möchten, hier ist ein guter Artikel, der JSON und XML vergleicht. Komprimierung und Deserialisierung auf Client-Seite Ich wähle JSON.
Viel Glück.
Die Kosten für die Serialisierung wären ungefähr gleich. Es ist unwahrscheinlich, dass es ein spürbarer Unterschied ist. Verwenden Sie das Format, das für Ihre Benutzer am komfortabelsten ist (da es sich um eine Konfigurationsdatei handelt).
Der tatsächliche Leistungsunterschied kann auftreten, wenn Sie das JSON oder XML über ein Netzwerk senden müssen. Dann hängt die Leistung davon ab, wie viel Zeug Sie senden, und da JSON normalerweise prägnanter als XML ist, wird es im Allgemeinen besser über ein Netzwerk funktionieren.
Tags und Links c# xml json serialization