试图测试2个JSON框架的性能 - 它看起来是否正确？

在我的应用程序中 - 我使用JSON进行序列化，并且到目前为止 - 我使用的是GSON。好吧，这是一种缓慢的特别是初始登录我加载对象的地方。试图测试2个JSON框架的性能 - 它看起来是否正确？

我探索了选项并找到了杰克逊。我做了循环和反序列化1000个样本对象的快速测试。杰克逊快了3倍-5倍。

现在，我构建了包装器，以便我可以在库之间切换并开始测试，同时并肩观看我从每个库中获取的内容。这里是我的代码：

public static <T> T fromJson(String json, Class<T> classOfT) throws Exception 
    { 
     T returnObject; 

     Long milliseconds = (new Date()).getTime(); 
     returnObject = MyGsonWrapper.getMyGson().fromJson(json, classOfT); 
     Long gsonTime = (new Date()).getTime() - milliseconds; 

     milliseconds = (new Date()).getTime(); 
     returnObject = MyJacksonWrapper.getMyJson().readValue(json, classOfT); 
     Long jacksonTime = (new Date()).getTime() - milliseconds; 

if (gsonTime < jacksonTime) 
     { 
      Log.d(LOG_TAG, "------------- GSON Wins by " + Long.toString(jacksonTime - gsonTime) + " object: " + classOfT.getName()); 
     } 
     else 
     { 
      Log.d(LOG_TAG, "------------- Jackson Wins by " + Long.toString(gsonTime - jacksonTime) + " object: " + classOfT.getName()); 
     }

有没有在我的代码如何获得时间测量流？底线是 - 不同的是微不足道的，GSON证明是可行的，所以我不知道。现实生活与我的初步评估不同。它不觉得更快杰克逊要么..

02-17 10:23:26.068: DEBUG/com.idatt.json.JsonWrapper(12004): ------------- GSON Wins by 108 object: [Lcom.idatt.json.UserPreference; 
02-17 10:23:28.006: DEBUG/com.idatt.json.JsonWrapper(12004): ------------- Jackson Wins by 34 object: [Lcom.idatt.json.MailTemplate; 
02-17 10:23:29.154: DEBUG/com.idatt.json.JsonWrapper(12004): ------------- GSON Wins by 27 object: [Lcom.idatt.json.MailItem; 
02-17 10:23:36.514: DEBUG/com.idatt.json.JsonWrapper(12004): ------------- Jackson Wins by 599 object: [Lcom.idatt.json.TripUser; 
02-17 10:23:50.260: DEBUG/com.idatt.json.JsonWrapper(12004): ------------- Jackson Wins by 1 object: [Lcom.idatt.json.TripUpdate; 
02-17 10:24:00.455: DEBUG/com.idatt.json.JsonWrapper(12004): ------------- GSON Wins by 45 object: java.lang.Integer 
02-17 10:24:00.541: DEBUG/com.idatt.json.JsonWrapper(12004): ------------- GSON Wins by 34 object: [Lcom.idatt.json.Device;

来源

2012-02-17 katit

要尝试和规范出VM的动态行为由于差异以及一个暖/冷JVM，尽量定时每次循环运行10000次，然后看看有什么不同。

另请注意，由于VM的随机性，第一组代码的运行时间与第二组的时间不同，所以触发这些，然后平均时间。

网络，我怀疑你会发现任何显着的差异。

另外：如果毫秒差异很大，看看这个流解析Jackson和GSON都提供了更快的原始访问（但是你将负责解析逻辑并重建你的对象，这可能是一个净损失）

来源

2012-02-17 17:34:00

如果我可以添加，如果毫秒有所作为，请查看不同的序列化协议。 – 2012-02-17 17:42:38

很好的答案，我想补充的唯一事情是只能在模拟器来测试在实际设备上的数字，而不是，因为在某些情况下，极端的差异。 – 2012-02-17 17:46:15

其实，这是我的愚蠢......所有的缓慢性将数据写入数据库（SQLite的）来，而不是从序列化。进行正确跟踪日志之后 - 我计算过，JSON解析是不是在所有的问题开始与... – katit 2012-02-17 17:46:43

通常的警告这里（谷歌的提示做Java性能测量，如果这些都是新）：

必须运行足够的测量，以稳定的时序结果 - JVM需要一段时间来优化代码（从字节码编译到本地）。这意味着至少有10秒左右的时间采取任何测量
千万不要错过字符串，除非您的输入必须为字符串之前 - 读输入，转换为字符串的开销一般是不必要的，最快的方式是在InputStream或通过byte[]' (or, for parsers that accept neither,读者built from InputStream`
（未成年人）不要构建Date秒;只需使用System.currentTimeMillis()（或'timeNanos`）获取时间。

我的猜测是，您可能已经忘记了第一部分，因此结果有些随意，并且从运行变为跑步。

来源

2012-02-18 22:46:56 StaxMan

试图测试2个JSON框架的性能 - 它看起来是否正确？

回答

相关问题