关于JSONModel和MJExtension的性能对比

最初我在微博上看到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.09_{0.14之前，JSONModel处在2.10}2.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.40_{0.45之间。怀疑使用keyMapper还是挺耗时的，于是将keyMapper这个方法注释掉，将desc这个属性按照JSONModel的使用规则改成实现了<Ignore>协议的类型，这样JSONModel会忽略这个属性的转换。发现效率果然又回去了，大概在0.15}0.17之间。看来JSONModel中这个优秀的特性还是需要不少代价的。至于MJExtension实现中的keyMapper类似实现中关于性能代价的问题，这里还没有做测试。

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