試圖測試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框架的性能 - 它看起來是否正確？

回答

相關問題