论坛首页 Java企业应用论坛

fastjson发布1.1.0版本

浏览 16004 次
该帖已经被评为良好帖
作者 正文
   发表时间:2011-07-18   最后修改:2011-07-18
这个版本引入了asm优化encode和decode的性能,使用了新的预测读取优化算法,大幅度提升了decode的性能。这个版本没有bug fixed。

Improvement
[FASTJSON-51] - 提供按字段名称顺序输出,具体信息 http://code.alibabatech.com/wiki/pages/viewpage.action?pageId=3637285

New Feature
[FASTJSON-49]- 提供兼容JSON-LIB的特性,具体信息: http://code.alibabatech.com/wiki/pages/viewpage.action?pageId=3637292
[FASTJSON-52] - 引入ASM优化序列化和反序列化性能。动态生成类,避免反射。
[FASTJSON-53] - 使用预测优化算法优化parser的性能,这个算法大幅度提升了parser的性能。

性能测试
使用https://github.com/eishay/jvm-serializers/提供的测试跑的结果如下:
  序列化时间 反序列化时间 大小 压缩后大小
java序列化 8703 41871 889 541
hessian 6453 9636 501 313
protobuf3020 1666 239 149
thrift 3160 1960 349 197
avro 3510 1949 221 133
jackson-databind 3007 4382 503 271
fastjson 2226 2896 468 251


ENCODE: java serialize 25.5%,hessian 34.4%,protobuf 73.7%,  jackson 74%,   thrift 70.4%,      avro 63.4%
DECODE: java serialize 6.9%,  hessian 30%,    protobuf 173.8%,jackson 66%,   thrift 147.7%,   avro 148.5%

fastjson性能已经很好了,你可以用来做如下事情:
1、替换json-lib
2、替换java序列化
3、替换hessian
4、缓存对象在memcached

How to get it?

If you're Maven user, just use our maven repository(http://code.alibabatech.com/mvn/releases/) with folloging dependency

<dependency>
     <groupId>com.alibaba</groupId>
     <artifactId>fastjson</artifactId>
     <version>1.1.0</version>
</dependency>


Binary http://code.alibabatech.com/mvn/releases/com/alibaba/fastjson/1.1.0/fastjson-1.1.0.jar
Source http://code.alibabatech.com/mvn/releases/com/alibaba/fastjson/1.1.0/fastjson-1.1.0-sources.jar
   发表时间:2011-07-18  
希望能够提供注解功能:
例如:@JsonIgnore
0 请登录后投票
   发表时间:2011-07-18  
melin 写道
希望能够提供注解功能:
例如:@JsonIgnore

有同样功能的:

@JSONField(serialize=false)
0 请登录后投票
   发表时间:2011-07-18   最后修改:2011-07-18
avro,我对他的性能和数据大小一直看得很心动,居然可以用protobuf在一个数量级,而且它还不像protobuf具有侵入性(不需要预先定义proto文件),有机会可以在项目中用下。

Lz,能详细介绍下"预测优化算法优化parser"的一些细节不?看着名字很诱人
0 请登录后投票
   发表时间:2011-07-18   最后修改:2011-07-18
agapple 写道
avro,我对他的性能和数据大小一直看得很心动,居然可以用protobuf在一个数量级,而且它还不像protobuf具有侵入性(不需要预先定义proto文件),有机会可以在项目中用下。

Lz,能详细介绍下"预测优化算法优化parser"的一些细节不?看着名字很诱人


两种模式,一种是快速模式,一种是常规模式。

快速模式时,他假定name:value对的顺序是固定,如果你使用fastjson,没有重新编译你的Value Object,他的顺序就是固定的。在快速模式时,速度是第一考虑,不需要把name从char[]中读取出来,而是直接拿name去匹配,如果匹配成功,就parseValue,一直匹配下去。如果失败,就退出快速模式,进入常规模式。

具体实现参考这里:
http://code.alibabatech.com/svn/fastjson/trunk/src/main/java/com/alibaba/fastjson/parser/JSONScanner.java

这个方法:
public int scanField(char[] fieldName, Object object, FieldDeserializer fieldDeserializer) {
}


以及这里:
http://code.alibabatech.com/svn/fastjson/trunk/src/main/java/com/alibaba/fastjson/parser/deserializer/JavaBeanDeserializer.java
public <T> T deserialze(DefaultExtJSONParser parser, Type type) {
}


快速模式假定的顺序是name:value,这种顺序通常是三种可能,第一种是fastjson自然序列化的顺序; 第二种,是fastjson通过SortField特性输出的顺序,第三种是某种其他parser的特性顺序。

目前快速模式只支持第一种顺序,其他两种顺序的实现还没做,都可以做的,而且不该有什么的性能开销。




0 请登录后投票
   发表时间:2011-07-18   最后修改:2011-07-18
感觉又在像看以前C/C++的程序,好熟悉for(;;)。

to温少,是不是可以这么理解:
1. 你这里scanField做的一个优化,就是将你的fieldname直接转化为char[]和原始的json字符串流进行匹配,如果匹配成功就直接获取对应的value进行输出。
2. 而原先的处理方式,在于将原先的json字符串流提取为对应name,然后再通过class的反射拿到对应的field,进行反射赋值处理。
3. 你这里的fieldname的处理顺序,也是基于在一次的正常反射扫描的结果后记录下对应的顺序信息

所以综合一下,其实你这里是减少了char[] -> string的一个处理 + class查找field的反射调用(或者cache查找)
0 请登录后投票
   发表时间:2011-07-18  
agapple 写道
感觉又在像看以前C/C++的程序,好熟悉for(;;)。

to温少,是不是可以这么理解:
1. 你这里scanField做的一个优化,就是将你的fieldname直接转化为char[]和原始的json字符串流进行匹配,如果匹配成功就直接获取对应的value进行输出。
2. 而原先的处理方式,在于将原先的json字符串流提取为对应name,然后再通过class的反射拿到对应的field,进行反射赋值处理。
3. 你这里的fieldname的处理顺序,也是基于在一次的正常反射扫描的结果后记录下对应的顺序信息

所以综合一下,其实你这里是减少了char[] -> string的一个处理 + class查找field的反射调用(或者cache查找)


你的分析是正确的,这个顺序是Class.getMethods()的顺序,还可以支持其他中顺序的,目前还没有实现。
0 请登录后投票
   发表时间:2011-07-18   最后修改:2011-07-18
重复,编辑掉
0 请登录后投票
   发表时间:2011-07-18  
wenshao 写道
agapple 写道
感觉又在像看以前C/C++的程序,好熟悉for(;;)。

to温少,是不是可以这么理解:
1. 你这里scanField做的一个优化,就是将你的fieldname直接转化为char[]和原始的json字符串流进行匹配,如果匹配成功就直接获取对应的value进行输出。
2. 而原先的处理方式,在于将原先的json字符串流提取为对应name,然后再通过class的反射拿到对应的field,进行反射赋值处理。
3. 你这里的fieldname的处理顺序,也是基于在一次的正常反射扫描的结果后记录下对应的顺序信息

所以综合一下,其实你这里是减少了char[] -> string的一个处理 + class查找field的反射调用(或者cache查找)


你的分析是正确的,这个顺序是Class.getMethods()的顺序,还可以支持其他中顺序的,目前还没有实现。


这个基于运行时上一个运行的结果的分析&优化,我在自己的mapping映射中也做过类似。就是将多次的pojo bean的field/method反射调用合并为一次batch请求(转化为类似beanCopier的模式,批量的get和批量的set),通过asm字节码增强,是不是也可以考虑下?
0 请登录后投票
   发表时间:2011-07-18   最后修改:2011-07-18
说的对,这也是一种优化办法,batchSet应该能够提高性能,这个建议很好,打算在1.1.1中实现 :)
0 请登录后投票
论坛首页 Java企业应用版

跳转论坛:
Global site tag (gtag.js) - Google Analytics