Ich habe ein Programm geschrieben, um eine Person-Klasse mit XMLSerializer, BinaryFormatter und ProtoBuf zu serialisieren. Ich dachte protobuf-net sollte schneller sein als die anderen beiden. Die Protobuf-Serialisierung war schneller als die XML-Serialisierung, aber viel langsamer als die Binärserialisierung. Ist mein Verständnis falsch? Bitte lass mich das verstehen. Danke für die Hilfe.
BEARBEITEN: - Ich habe den Code geändert (unten aktualisiert), um die Zeit nur für die Serialisierung zu messen und die Streams nicht zu erstellen und trotzdem den Unterschied zu sehen. Kann mir einer sagen warum?
Folgendes ist die Ausgabe: :
Person wurde mit Protokollpuffer in 347 Millisekunden erstellt
Person wurde mit XML in 1462 Millisekunden erstellt
Person wurde in 2 Millisekunden mit Binärcode erstellt
Code unten
%Vor%Ich habe auf Ihre E-Mail geantwortet; Ich wusste nicht, dass du es auch hier gepostet hast. Die erste Frage, die ich habe, ist: Welche Version von Protobuf-Net? Der Grund, warum ich frage, ist, dass die Entwicklung Trunk von "v2" absichtlich Auto-Compilation deaktiviert hat, so dass ich meine Komponententests verwenden kann, um sowohl die Laufzeit als auch vorkompilierte Versionen zu testen. Wenn Sie also "v2" verwenden (nur in der Quelle verfügbar), müssen Sie ihm mitteilen, dass das Modell kompiliert werden soll - andernfalls wird eine 100% ige Reflexion ausgeführt.
In "v1" oder "v2" können Sie dies mit:
tun %Vor%Nachdem ich das getan habe, die Zahlen, die ich bekomme (aus dem Code in Ihrer E-Mail; ich habe nicht überprüft, ob das obige das gleiche Beispiel ist):
%Vor% Der andere Faktor sind die Wiederholungen; 3-10ms ist ehrlich gesagt nichts; Sie können Zahlen auf dieser Ebene nicht vergleichen. Um es zu wiederholen, 5000-mal zu wiederholen (Wiederverwendung der XmlSerializer / BinaryFormatter Instanzen; keine falschen Kosten eingeführt) Ich bekomme:
Nimm dies zu schärferen Extremen (100000):
%Vor%Also letztlich:
Beachten Sie auch, dass das kompilierte Modell in "v2" vollständig statisch kompiliert werden kann (zu einer DLL, die Sie bereitstellen können), wodurch sogar die (bereits kleinen) Hochlaufkosten entfernt werden.
Ich habe eine etwas andere Meinung als die markierte Antwort. Ich denke, die Zahlen aus diesen Tests spiegeln den Metadaten-Overhead von Binärformatierer wider. BinaryFormatter schreibt zuerst Meta-Daten über die Klasse, bevor Daten geschrieben werden, während Protobuf nur Daten schreibt.
Für das sehr kleine Objekt (ein Person-Objekt) in Ihrem Test wiegen die Metadaten-Kosten von binärem Formatierer mehr als echte Fälle, weil es mehr Metadaten als Daten schreibt. Wenn Sie also die Anzahl der Wiederholungen erhöhen, sind die Kosten für die Metadaten übertrieben, bis auf das gleiche Niveau wie bei der XML-Serialisierung im Extremfall.
Wenn Sie ein Person-Array serialisieren und das Array groß genug ist, sind die Metadatenkosten für die Gesamtkosten trivial. Dann sollte der binäre Formatierer ähnlich wie Protobuf für Ihren extremen Wiederholungstest funktionieren.
PS: Ich habe diese Seite gefunden, weil ich verschiedene Serialisierer auswerte. Ich habe auch einen Blog Ссылка zeigt Testergebnis, dass DataContractSerializer + binary XmlDictionaryWriter mehrere Male besser als Binärformatierer durchführt. Es wurde auch mit sehr kleinen Daten getestet. Als ich den Test selbst mit großen Daten durchführte, war ich überrascht, dass das Ergebnis sehr unterschiedlich war. Also testen Sie mit echten Daten, die Sie tatsächlich verwenden.
Wir serialisieren ziemlich große Objekte (etwa 50 Eigenschaften) ständig, also habe ich einen kleinen Test geschrieben, um BinaryFormatter und protobuf-net zu vergleichen, genau wie du es getan hast und hier sind meine Ergebnisse (10000 Objekte):
%Vor%Das ist offensichtlich ein sehr auffälliger Unterschied. Es ist auch viel schneller beim zweiten Lauf (die Tests sind genau gleich) als bei der ersten.
Aktualisieren. RuntimeTypeModel.Add..Compile erzeugt folgende Ergebnisse:
%Vor%Tags und Links serialization protobuf-net