坊间有非常多的 C/C++ JSON 库，怎么选择是一个难题。
[nativejson-benchmark](https://github.com/miloyip/nativejson-benchmark)应该是史上第一个评测了28个C/C++开源JSON程序库的开源项目，它评测了每个库是否符合 JSON 标准 (RFC7159, ECMA-404)，并且在性能上测试了各个操作（如解析、生成）的耗时、内存用量等数据，甚至可执行文件的大小也有统计。
这个项目也希望能够通过互相学习借镜，提升现时或未来的 JSON 程序库品质。
由于每个评测也不能完全覆盖所有数据及软硬件组合，建议使用者可自行在所需的平台和数据下进行测试。
以下是 iMac (Corei5-3330S@2.70GHz) 及clang 6.1_1 64-bit下的部分结果，详情可访问这里。
符合标准程度（越高越好）：
解析至DOM的时间（越低越好）：
解析至DOM后的内存（越低越好）：
把DOM生成JSON的时间（越低越好）：
把DOM生成含换行及缩进的JSON的时间（越低越好）：
可执行文件（把JSON解析至DOM，然后统计JSON类型）的大小（越低越好）：
引用来自“calvinwilliams”的评论
rapidjson出新版了？我去试试先。好奇的问下，在你的环境里，解析一个json报文，作为一条记录插入数据库，需要手工编写代码是怎么样的？我的写法已经在前面演示了。
我现在倒是觉得c语言搞开发，更关注的应该是开发效率和稳定性吧（运行效率可以通过分布式架构来更有效的提高），大量分配内存、大量操作指针、解析json插入数据库需要手工编写大量代码，都不是好的开发方式和工具风格，你说呢 ^_^ 望互相学习互相提高
引用来自“calvinwilliams”的评论
http://git.oschina.net/calvinwilliams/fasterjson/blob/master/README-CN国产原创的C语言接口的fasterjson+DirectStruct含笑不语
另外，关于测试集，我用的也是你原本的测试集，对于test_big2.json，不是RapidJson不能解析，而是RapidJson不支持 // 和 /* */ 的注释，所以把前面的注释移除就可以测试了。
引用来自“calvinwilliams”的评论
fasterjson快的主要原因是：内部无任何内存分配；很多内部函数调用改成宏展开，代码极端优化。某银行内部大量采用，性能杠杠的。
引用来自“shines77”的评论
其实RapidJson也提供这种做法的, 叫做原位解析Insitu, 即是测试图里面的RapidJson_Insitu. 你的代码粗略看了一下, 并没有什么特别可取的地方, 相反, 有不少冗余的东西.引用来自“calvinwilliams”的评论
好吧，我的代码没有什么特别可取的地方, 有不少冗余的东西 -_-!!!引用来自“calvinwilliams”的评论
fasterjson快的主要原因是：内部无任何内存分配；很多内部函数调用改成宏展开，代码极端优化。某银行内部大量采用，性能杠杠的。
引用来自“shines77”的评论
其实RapidJson也提供这种做法的, 叫做原位解析Insitu, 即是测试图里面的RapidJson_Insitu. 你的代码粗略看了一下, 并没有什么特别可取的地方, 相反, 有不少冗余的东西.好奇的问下，在你的环境里，解析一个json报文，作为一条记录插入数据库，需要手工编写代码是怎么样的？我的写法已经在前面演示了。
我现在倒是觉得c语言搞开发，更关注的应该是开发效率和稳定性吧（运行效率可以通过分布式架构来更有效的提高），大量分配内存、大量操作指针、解析json插入数据库需要手工编写大量代码，都不是好的开发方式和工具风格，你说呢 ^_^ 望互相学习互相提高
引用来自“Abeldu”的评论
RapidJSON软文~~引用来自“MiloYip”的评论
花这么多时间去测试，给出数据，然后说是软文？court_shixin_person person ;
fp = fopen( p_task->pathfilename , "r" ) ;
...
nret = fread( filebuffer , 1 , sizeof(filebuffer) , fp ) ;
...
memset( & person , 0x00 , sizeof(court_shixin_person) );
nret = DSCDESERIALIZE_JSON_court_shixin_person( NULL , bufferptr , & nret , & person ) ;
...
strcpy( person.update_flag , "1" ); /* 新增 */
DSCSQLACTION_INSERT_INTO_court_shixin_person( & person );
...
怎么样，用c语言处理json数据是不是和java一样便捷？从c结构体打包成json报文也一样只要调个函数即可 ^_^
目前fasterjson只支持GBK编码，UTF8未验证，后面会验证并支持。
为了解析如下json数据
{"id":876500,"iname":"李**","caseCode":"(2014)秦执字第02203号","age":34,"sexy":"男",...
我先编写dsc定义文件
STRUCT court_shixin_person
{
INT 4 id NOTNULL # 序号
STRING 128 iname # 被执行人姓名
STRING 256 caseCode # 案号
INT 4 age # 年龄
STRING 4 sex # 性别
...
SQLACTION "INSERT INTO court_shixin_person"
...
使用工具处理该文件
dsc -f IDL_court_shixin_person.dsc -c -c-LOG -c-json -sql-pgsql -ec-pgsql
自动生成了很多代码，我在我的应用代码里直接调用自动生成的解析json函数到c结构体，再调用从c结构体插入到数据库表函数，就能完成从解析json报文到入数据库，我所写的程序仅仅调用了两个前面自动生成好的函数。
nret = DSCDESERIALIZE_JSON_court_shixin_person( NULL , bufferptr , & nret , & person ) ;
...
DSCSQLACTION_INSERT_INTO_court_shixin_person( & person );
http://git.oschina.net/calvinwilliams/DirectStruct/blob/master/README-CN
写一个dsc定义文件，用工具dsc处理之，自动生成调用fasterjson的自动化代码，包含c结构体定义、c结构体与json报文之间互相转换的函数，用户程序操作json数据变成了只操作c结构体变量即可，没有漫天飞的指针。漫天飞的指针恰恰是其它开源json解析库的通病，大量使用指针可是对c程序员的考验啊，呵呵。
引用来自“Abeldu”的评论
RapidJSON软文~~引用来自“MiloYip”的评论
花这么多时间去测试，给出数据，然后说是软文？引用来自“calvinwilliams”的评论
在fasterjson内部，数字按字符串解析。为了提高性能，fasterjson只提示数据的位置和长度，用户程序按需自行提取，而不是无论用户要不要数据，都提取出来，所以fasterjson本身不用处理转义符，但是头文件中也包含了处理转义符的宏，用户可根据情况额外调用。
具体可参见fasterjson的伴侣工具DirectStruct的自动生成的代码。
我们的目标是：让c语言环境处理json格式数据方便到极致。
看到代码里用了strchr()等API，建议改写来提高性能。
引用来自“calvinwilliams”的评论
fasterjson快的主要原因是：内部无任何内存分配；很多内部函数调用改成宏展开，代码极端优化。某银行内部大量采用，性能杠杠的。
引用来自“MiloYip”的评论
如果不符合标准，那么性能是无意义的。引用来自“Abeldu”的评论
RapidJSON软文~~为了提高性能，fasterjson只提示数据的位置和长度，用户程序按需自行提取，而不是无论用户要不要数据，都提取出来，所以fasterjson本身不用处理转义符，但是头文件中也包含了处理转义符的宏，用户可根据情况额外调用。
具体可参见fasterjson的伴侣工具DirectStruct的自动生成的代码。
我们的目标是：让c语言环境处理json格式数据方便到极致。
引用来自“calvinwilliams”的评论
fasterjson快的主要原因是：内部无任何内存分配；很多内部函数调用改成宏展开，代码极端优化。某银行内部大量采用，性能杠杠的。
某银行内部大量采用，性能杠杠的。
引用来自“Abeldu”的评论
RapidJSON软文~~go 就是自带标准库，省心。
引用来自“尾鱼头”的评论
strdup是个什么玩意