redux、immutablejs和mobx性能對比(三)

4、個人結論html

  經過第三部分的數據數據分析,我以爲咱們能夠獲得如下結論:react

  1. 不管是在開發環境仍是測試環下頁面的首次加載速度結果都是:redux>immutablejs>mobx,可是他們之間的差距並非很大。
  2. 10000條-100000條數據的頁面加載時間的增量明顯也高於10000-1000條數據的頁面加載時間增量。
  3. 不管是在開發環境仍是生產環境下點擊完成某個todo所需的頁面渲染速度結果都是:mobx>immutablejs>redux,正好和頁面的首次加載時間相反,可是它們之間的差距仍是蠻大的,具體表如今:
    • mobx的渲染速度一騎絕塵大幅度領先其它二者,尤爲是在開發環境下,並且數據量越多越明顯。
    • immutablejs和redux的差距在1000條和10000條數據時並不明顯,可是在100000條數據的時候有了明顯差距。
    • mobx在1000條到100000條數據的增量並不明顯幅度很小,尤爲是開發環境下,與此同時redux的增量要大於immutablejs,immutablejs大概處於它們倆之間。

   從第三部分的統計圖上我目前能看到的信息就是這麼多,聰明的你沒準可以得出更多有用的信息,因此我把個人測試數據以及統計原圖的git倉庫打在下面,大家能夠盡情的下載查看分析:git

   https://github.com/kwzm/redux-immutablejs-mobx-performance-testgithub

5、深刻的思考算法

  其實若是讀到這裏,我相信你和我同樣雖然經過紙面的數據獲得了想要的結論,可是腦海裏仍是有各類疑問:chrome

    • 爲何mobx的用戶操做渲染速度會那麼快
    • 影響它們三者渲染速度的罪魁禍首又是誰

   下面來讓我經過一組圖片來爲大家解開這其中的原因:redux

   我選取了生產環境下10000條數據時,chrome的performance面板上的Summary餅狀圖來做爲實例segmentfault

   從左往右依次爲redux、immutablejs和mobx佈局

  

    我先介紹一下餅狀圖裏面各項的含義:性能

    • 黃色(Scripting):JavaScript執行
    • 紫色(Rendering):樣式計算和佈局,即重排
    • 綠色(Painting):重繪
    • 灰色(other):其它事件花費的時間
    • 白色(Idle):空閒時間

    從中咱們能夠看到雖然出了Scripting其它四項也有差別,可是差別並不大,最大的差別點仍是Scripting,也就是說js代碼的執行時間纔是影響三者性能的主要緣由,那麼爲何三者的js執行時間會有如此大的差別呢?爲了解釋這個問題,我在每一個組件的render方法中添加了console.log語句,讓我看看當點擊操做發生後控制檯輸出了什麼。

    在此以前,我先簡單介紹一下todoList的組件結構:

    • App
      • TodoHeader
      • TodoList
        • TodoItem
        • TodoItem
        • ......
      • TodoFooter

     從左往右依次是redux、immutablejs和mobx:

  

    從console面板咱們能夠看出mobx爲何js執行時間最短,由於它只有兩個組件執行了render方法,兩個必要的組件,而縱觀其它二者都有些沒必要要的render,雖然react的diff算法已經很快了,可是當數據量達到必定規模的時候,這種沒必要要的render會越積越多,形成了內存和cpu的性能浪費。

    至於爲何它們三者對於同一個事件執行的render方法會如此不一樣,這個並不在本文的探討範圍以內,這個涉及到這三者的原理,請你們自行百度吧。

6、參考資料

   一、源碼

  二、測試數據及圖表

  三、性能測試

7、最後的話

  其實我以前也從網上想找些現成的資料,可是無奈沒有找到,因此藉由目前正在學習immutablejs和mobx之機,隨便作下性能的測試,可是其實這方面我徹底是小白,包括如何進行性能測試,如何分析數據,我都是第一次作,因此若是有哪塊不正確還請您指出,咱們共同窗習,謝謝!

 

   此乃做者原創做品,如需轉載,請在標題標明【轉載】並附上原文連接,謝謝。

相關文章
相關標籤/搜索