Benutzer424060
Ich brauche einen C++ JSON-Parser und -Writer. Geschwindigkeit und Zuverlässigkeit sind sehr kritisch, es ist mir egal, ob die Schnittstelle schön ist oder nicht, ob sie auf Boost basiert oder nicht, selbst ein C-Parser ist in Ordnung (wenn er erheblich schneller als C++ ist).
Wenn jemand Erfahrung mit der Geschwindigkeit verfügbarer JSON-Parser hat, teilen Sie dies bitte mit.
Milo Yip
rapidjson ist ein C++ JSON-Parser/-Generator, der auf Schnelligkeit und geringen Speicherbedarf ausgelegt ist.
Da ist ein Leistungsvergleich mit YAJL und JsonCPP.
Aktualisieren:
Ich habe ein Open-Source-Projekt erstellt Nativer JSON-Benchmark, das 29 (und mehr) C/C++ JSON-Bibliotheken in Bezug auf Konformität und Leistung bewertet. Dies sollte eine nützliche Referenz sein.
rapidjson, mit Ausnahme aller Vorverarbeitungsmakros und des Aufrufs von setjmp Es scheint eine nette Bibliothek zu sein.
– dalle
11. August 2013 um 21:15 Uhr
Danke! Jetzt bin ich von einer Parsing-Zeit von über 7 Sekunden in JsonCpp auf 1,5373 gekommen.
– Martijn Mellens
14. Januar 2014 um 15:02 Uhr
@dalle Nur als Update, setjmp ist seit einigen Jahren entfernt. Danke trotzdem für deinen Kommentar.
– Milo Yip
4. Januar 2016 um 3:41 Uhr
Ich weiß nicht wirklich, wie sie sich in Bezug auf die Geschwindigkeit vergleichen, aber die erste scheint die richtige Idee für die Skalierung auf wirklich große JSON-Daten zu sein, da sie jeweils nur einen kleinen Teil analysiert, sodass sie nicht alle Daten speichern müssen Arbeitsspeicher auf einmal (Dies kann je nach Bibliothek/Anwendungsfall schneller oder langsamer sein)
Kert
https://github.com/quartzjer/js0n
Die hässlichste Schnittstelle, die möglich ist, aber tut, was Sie verlangen. Nullzuweisungen.
http://zserge.com/jsmn.html
Ein weiterer Zero-Allocation-Ansatz.
Die vor allem geposteten Lösungen führen eine dynamische Speicherzuweisung durch und werden daher abhängig von der Datenstruktur irgendwann zwangsläufig langsamer sein – und es ist gefährlich, sie in eine Umgebung mit Heap-Beschränkung wie ein eingebettetes System aufzunehmen.
Benchmarks von vjson, rapidjson und sajson hier: http://chadaustin.me/2013/01/json-parser-benchmarking/ wenn dich sowas interessiert.
Und um Ihren “Schriftsteller” -Teil der Frage zu beantworten, bezweifle ich, dass Sie einen effizienten schlagen könnten
printf("{%s:%s}",name,value)
Implementierung mit jeder Bibliothek – vorausgesetzt, Ihre printf/sprintf-Implementierung selbst ist natürlich leichtgewichtig.
BEARBEITEN: Lassen Sie mich das zurücknehmen, RapidJson erlaubt die Zuweisung auf dem Stapel nur über seinen MemoryPoolAllocator und macht dies tatsächlich zu einem Standard für seinen GenericReader. Ich habe den Vergleich nicht durchgeführt, aber ich würde erwarten, dass es robuster ist als alles andere, was hier aufgeführt ist. Es hat auch keine Abhängigkeiten und löst keine Ausnahmen aus, was es wahrscheinlich letztendlich für Embedded geeignet macht. Vollständig Header-basierte Bibliothek, daher einfach überall einzubinden.
Wie kann man sich nicht um die Nettigkeit einer Bibliotheks-API kümmern?
– Benoît
18. August 2010 um 15:50 Uhr
Ich kümmere mich um die Nettigkeit der API, aber die meisten verfügbaren Bibliotheken neigen dazu, die Geschwindigkeit zu opfern, wenn sie versuchen, die Benutzeroberfläche schön und einfach zu bedienen. Für mein Projekt ist Geschwindigkeit eine der wichtigsten Anforderungen.
– Benutzer424060
19. August 2010 um 2:05 Uhr
Ich verstehe die Stimmung. Aber ich würde stets Wählen Sie zuerst die am besten unterstützte / am besten entworfene Bibliothek aus und erstellen Sie einen Prototyp davon, um zu überprüfen, ob sich die JSON-Implementierung überhaupt auf dem kritischen Pfad befindet und ob Abstriche in Bezug auf Lesbarkeit / Wartbarkeit tatsächlich sinnvoll sind. Messen, optimieren, messen.
– DevSolar
14. November 2012 um 9:55 Uhr
Es gibt einen Benchmark mit 28 C/C++ JSON-Bibliotheken: github.com/miloyip/nativejson-benchmark
– Milo Yip
28. April 2015 um 13:39 Uhr
@ user424060: Ich weiß, das ist alt, aber diese Mentalität ist der Grund, warum Programme heute bestenfalls so schnell laufen wie ihre Äquivalente von 1990
– Ed S.
7. April 2017 um 21:49 Uhr