Ho bisogno di un parser JSON C++ & writer. La velocità e l'affidabilità sono molto critiche, non mi interessa se l'interfaccia è bella o meno, se è basata su Boost o meno, anche un parser C va bene (se è considerevolmente più veloce di quelli C++).Lettore/scrittore JSON più veloce per C++
Se qualcuno ha esperienza con la velocità dei parser JSON disponibili, si prega di avvisare.
non so davvero come si confronta per la velocità, ma il primo sembra l'idea giusta per la scalatura ai dati JSON davvero grande, dal momento che analizza solo un piccolo pezzo a un tempo quindi non è necessario tenere tutti i dati in memoria in una volta (Questo può essere più veloce o più lento a seconda della libreria/caso d'uso)
rapidjson è un parser/generatore JSON C++ progettato per essere veloce e piccolo impronta di memoria.
C'è un performance comparison con YAJL e JsonCPP.
Aggiornamento:
ho creato un progetto open source Native JSON benchmark, che valuta 29 (e crescente) librerie C/C++ JSON, in termini di conformità e le prestazioni. Questo dovrebbe essere un riferimento utile.
rapidjson, ad eccezione di tutte le macro di preelaborazione e la chiamata a 'setjmp' sembra una bella libreria. – dalle
grazie! Ora ho ottenuto un tempo di analisi di 7+ secondi in JsonCpp a 1,5373. –
@dalle Proprio come aggiornamento, 'setjmp' è stato rimosso per alcuni anni. Grazie per il tuo commento comunque. –
https://github.com/quartzjer/js0n
più brutto interfaccia possibile, ma fa quello che chiedi. Assegnazioni zero.
http://zserge.com/jsmn.html Un altro approccio di allocazione zero.
Le soluzioni pubblicate soprattutto eseguono l'allocazione dinamica della memoria, quindi a un certo punto saranno inevitabilmente rallentate, a seconda della struttura dei dati, e saranno pericolose da includere in un ambiente con heap limitato come un sistema embedded.
Benchmark di vjson, rapidjson e sajson qui: http://chadaustin.me/2013/01/json-parser-benchmarking/ se siete interessati a questo genere di cose.
E per rispondere alla tua parte "writer" della questione dubito che si potrebbe battere un efficace attuazione
printf("{%s:%s}",name,value)
con qualsiasi libreria - supponendo che l'implementazione printf/sprintf sé è leggero, naturalmente.
EDIT: in realtà mi consente di riprenderlo, RapidJson consente l'allocazione dello stack solo tramite il suo MemoryPoolAllocator e in effetti lo rende un valore predefinito per GenericReader. Non ho fatto il confronto ma mi aspetterei che sia più robusto di qualsiasi altra cosa elencata qui. Inoltre non ha alcuna dipendenza e non genera eccezioni che probabilmente lo rendono in definitiva adatto per l'embedded. Completamente basato su header, quindi facile da includere ovunque.
Come non si cura della gradevolezza di un'API di libreria? –
Mi interessa la gradevolezza dell'API ma la maggior parte delle librerie avaibale tendono a sacrificare la velocità quando cercano di rendere l'interfaccia piacevole e facile da usare. Per la mia velocità di proiezione è uno dei requisiti più importanti. – user424060
Capisco il sentimento.Ma dovrei * sempre * scegliere per prima cosa la libreria meglio supportata/meglio progettata, e costruirne un prototipo, per verificare se l'implementazione JSON è sul percorso critico e se eventuali sacrifici in termini di leggibilità/manutenibilità effettivamente ha senso. Misura, ottimizza, misura. – DevSolar