锁定老帖子 主题:fastjson发布1.1.0版本
该帖已经被评为良好帖
|
|||||||||||||||||||||||||||||||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
作者 | 正文 | ||||||||||||||||||||||||||||||||||||||||
发表时间:2011-07-18
最后修改:2011-07-18
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/提供的测试跑的结果如下:
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 声明:ITeye文章版权属于作者,受法律保护。没有作者书面许可不得转载。
推荐链接
|
|||||||||||||||||||||||||||||||||||||||||
返回顶楼 | |||||||||||||||||||||||||||||||||||||||||
发表时间:2011-07-18
希望能够提供注解功能:
例如:@JsonIgnore |
|||||||||||||||||||||||||||||||||||||||||
返回顶楼 | |||||||||||||||||||||||||||||||||||||||||
发表时间:2011-07-18
melin 写道 希望能够提供注解功能:
例如:@JsonIgnore 有同样功能的: @JSONField(serialize=false) |
|||||||||||||||||||||||||||||||||||||||||
返回顶楼 | |||||||||||||||||||||||||||||||||||||||||
发表时间:2011-07-18
最后修改:2011-07-18
avro,我对他的性能和数据大小一直看得很心动,居然可以用protobuf在一个数量级,而且它还不像protobuf具有侵入性(不需要预先定义proto文件),有机会可以在项目中用下。
Lz,能详细介绍下"预测优化算法优化parser"的一些细节不?看着名字很诱人 |
|||||||||||||||||||||||||||||||||||||||||
返回顶楼 | |||||||||||||||||||||||||||||||||||||||||
发表时间: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的特性顺序。 目前快速模式只支持第一种顺序,其他两种顺序的实现还没做,都可以做的,而且不该有什么的性能开销。 |
|||||||||||||||||||||||||||||||||||||||||
返回顶楼 | |||||||||||||||||||||||||||||||||||||||||
发表时间: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查找) |
|||||||||||||||||||||||||||||||||||||||||
返回顶楼 | |||||||||||||||||||||||||||||||||||||||||
发表时间: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()的顺序,还可以支持其他中顺序的,目前还没有实现。 |
|||||||||||||||||||||||||||||||||||||||||
返回顶楼 | |||||||||||||||||||||||||||||||||||||||||
发表时间:2011-07-18
最后修改:2011-07-18
重复,编辑掉
|
|||||||||||||||||||||||||||||||||||||||||
返回顶楼 | |||||||||||||||||||||||||||||||||||||||||
发表时间: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字节码增强,是不是也可以考虑下? |
|||||||||||||||||||||||||||||||||||||||||
返回顶楼 | |||||||||||||||||||||||||||||||||||||||||
发表时间:2011-07-18
最后修改:2011-07-18
说的对,这也是一种优化办法,batchSet应该能够提高性能,这个建议很好,打算在1.1.1中实现 :)
|
|||||||||||||||||||||||||||||||||||||||||
返回顶楼 | |||||||||||||||||||||||||||||||||||||||||