关于JSONModel和MJExtension的性能对比

96
贝勒老爷
2018.08.15 11:18* 字数 1471

最初我在微博上看到MJExtension的发布的时候,声称它比其他JSONModel等其他Data model快上好多倍,当时我正在用JSONModel,感觉这个事情很神奇,但是一直没有去看看MJExtension具体是怎么做到的。在MJ的github上看到有一个JSONTest的“性能测试”项目,于是刚刚我就直接打开运行先看了看结果。JSONModel的运行结果却是让我有些吃惊,以前的数据量都比较小让我都忽略了那个结果。

MJExtension的实现还没完全看完,但是不得不说它的实现却是相比JSONModel精简得多,但是这会儿我对它是怎么快的不太好奇,更多的是为什么JSONModel在相比之下那么慢。简单用Instruments中的Time Profiler功能测试了一下,以下所有结果是在我个人机器上(MBP late 2013, OSX 10.10.4, Xcode 6.4, iOS Simulator/iPhone 6)运行的结果,直接运行的是MJ的JSONTest项目master分支最新源码(文章最后有链接)。

在不修改任何的情况下:

6631235990978010303.png
6631433903071009743.png

MJExtension很好地处在0.090.14之前,JSONModel处在2.102.40之间,完全不在一个数量级上。

在Instruments里看到的结果:

6631387723582642295.png

[JSONValueTransformer __NSDateFromNSString:]这个方法执行消耗了最多的时间,看看JSONModel中这个方法的实现:

6630325595351291959.png

往更深一层看到,原来是NSDateFormatter在转换字符串的时候消耗了非常多的时间,累计1000+ms。反向测试一下是不是真的是NSString和NSDate之间的这种转换消耗了太多的时间,于是尝试不让JSON中的时间字符串转换成model class中的NSDate。

将GitHubRepoModel这类中的created和pushed从NSDate改成NSString类型,再次运行之后看结果:

6631199707094293816.png

立马将传说中的“倍数”结果拉到了同一个量级,还不错。看来罪魁祸首确实是NSDateFormatter的转换效率。简单搜索了一下MJExtension的实现,没有找到NSDateFormatter的结果。我在MJTest工程中做了同样的改动后测试,发现确实结果和改之前没有什么区别。

差距是拉小了,但是可能还有其他的原因。于是通过Time Profiler发现了一个第二大耗时的地方,其实上面的一张Intruments截图中就能看出来,图中选中行的下两行有一个[JSONModel description]的方法也挺显眼的,最后发现JSONModel出于方便debug的需求,重写了来自NSObject类中的description方法,下面是源码截图:

6630613667398298049.png

为了测试转换效率问题我注掉了这个方法实现,直接return nil;代替。然后看看运行结果,

6631427306001242991.png

终于把差距又拉小了好几倍,这下MJExtension和JSONModel之间的效率转换倍数已经很小了,小于两倍。把转换的测试数目从100调整到1000,结果也不到但是接近两倍。

说到description方法,调用这个方法的地方一般情况下是在lldb里通过po命令打印某个对象值得时候用到的。一般情况下不会用到这个方法,也就是说,在Release(非Debug)模式下,description是不会影响效率转换的。

问题又来了,为什么MJ的JSONTest/JSONModelTest会在没有使用po命令的情况下调用这个description方法?简单打了个断点,从调用栈上看,应该是测试使用中的model class中有一个description属性。其实Xcode已经给出了警告:

$/JSONTest/JSONModelTest/JSONModelTest/GitHubRepoModel.h:22:41: Auto property synthesis will not synthesize property 'description' because it is 'readwrite' but it will be synthesized 'readonly' via another property

GitHubRepoModel这个类重复定义了description这个属性,在其.m文件中又没有用@dynamic关键词指定描述导致两个属性被视为同一个属性。看来真的不要随意忽略警告啊,特别是一些陌生的警告。

description这个名字我们是不能在model class里面直接用了,按照JSONModel的规则必须重写一个类方法修改映射:

6630169464700145691.png

同时将原类中description属性名修改为desc,运行后发现结果现在回升到了0.400.45之间。怀疑使用keyMapper还是挺耗时的,于是将keyMapper这个方法注释掉,将desc这个属性按照JSONModel的使用规则改成实现了<Ignore>协议的类型,这样JSONModel会忽略这个属性的转换。发现效率果然又回去了,大概在0.150.17之间。看来JSONModel中这个优秀的特性还是需要不少代价的。至于MJExtension实现中的keyMapper类似实现中关于性能代价的问题,这里还没有做测试。

就说到这里,这篇文章主要是为了记录JSONModel为什么转换效率的问题(1. 使用了NSDateFormatter在转换NSString到NSDate之间的低效率。 2. json key名称和model class属性名之间的快捷映射是需要一定代价的),另外,也指出了MJ的JSONTest在对这两个class modeling 作对比时候的参考因素不当的问题。从结果上看,MJExtension的对比结果确实还是很让人满意的,而且是我国人写的框架,这一点确实还是非常赞的!

相关链接:

JSONTest的源码地址:https://github.com/CoderMJLee/JSONTest
MJExtension的源码地址:https://github.com/CoderMJLee/MJExtension
JSONModel的源码地址:https://github.com/icanzilb/JSONModel

iOS
Web note ad 1