如何評價效能大幅提升的Chrome 53?
itlr2016-06-15 07:26:59對Mobile更有意義，特別是webview裡的hybrid App
魯小夫2016-06-15 09:47:56說的是渲染效能上的提升，主要就是改進了 renderer ，利用 GPU 的效率更高了。
知乎使用者2016-06-15 13:07:03------ 6. 18. 2016 更新 ------
——-新增 有關記憶體佔用的問題——-
# 前言
先來聊聊 Chrome 的故事， Chrome 昔日曾以 V8 引擎一騎絕塵的執行速度碾壓對手，榮登為快不破之榜首，只是驚喜之後，越來越多的使用者發現超高速引擎的背後是大量的記憶體佔用，隨後越來越多的人開始抱怨聲討 Chrome 記憶體佔用問題，人類的不滿足和抱怨是天性，也正是這一點使我們現在比過去做的更好。也或許正是這些抱怨起了作用，在 Chrome 53 中，迎來了絕對是 chrome 目前為止史上最大幅度效能的提升。或許過去沒有，未來也不會再有。Chrome 53 只有一個，時光飛逝，即便 Chrome 65 、chrome 78 來臨，我們回想這個遙遠的午後，還會為第一次見如此恐怖的效能提升為之驚訝和感嘆往昔崢嶸。。
# 總體對比：
1。 Chrome 53， 在 Mac 上的表現，相對於 Chrome 51 總體上提升46。9%
2。 Chrome 53， 在 Android 上的表現，相對於 Chrome 51 總體上提升了 209%
3。 在 iPad Air 2 下的 safari 與 android M 下的 Chrome 53 對比，提升了 103%
4。 Chrome 53 與 Safari 在 Mac 下的對比，提升 -1。78%，真的是 -1。78%
如果以上的資料如果還沒讓你驚訝，或許下面的細節提升程度會讓你覺得這不符合科學，就好象違反了
弗雷德裡克·布魯克斯
在其著作《人月神話》中說的那樣：計算機語言對效能提升程度，遠遠趕不上硬體上的摩爾定律。但冰冷冷的數字就在下面，你看或者不看，它就在那裡，不增不減。
在 Mac 上的細節提升，主要體現在了 HTML 套件，和 SVG 渲染上，HTML 套件提升了大約 161%，測試資料都是針對相同平臺下的 Chrome 51 穩定版， SVG 套件提升了大約 151%。這只是開胃菜，然而你也知道：好戲還在後頭。。
也不知是 Google 也在徹底貫徹移動為先的時代，而有意針對自家移動裝置大幅度最佳化，還是純屬技術自然更新迭代，總之 Chrome 53 在移動裝置上的提升才是重頭戲，先來看看資料：
HTML 套件提升約 590%， SVG 套件提升 1087% ，雖然我數學一直不好，但不可否認這的確是一個恐怖的提升，也特別的好奇：之前的chrome在這方面的表現到底是有多差？
#
Chrome 53 為什麼這麼快？
使用基準試驗的情況下， 簡單來說，GPU的團隊改善了GPU的渲染瓶頸，使得 CSS 和 SVG 渲染更快，Canvas 和 WebGL 也表現的更好。
你也可以在chrome：//flags 下開啟 強制GPU柵格化（force gpu resterization），自行測試效能提升：
——force-gpu-rasterization
# 有關 Chrome 53 記憶體佔用多少的疑問
很多人都好奇這個版本的記憶體佔用是不是變大了啊，畢竟羊毛出在羊身上，要是這幾十年沒有硬體產品的更新迭代，效能提升，就算你底層最佳化的再好，也不可能野雞變鳳凰啊~~
但實際上，這次的效能提升，根據現有的官方文件說，chrome 團隊好像只是在 GPU 光柵渲染架構方面進行了調整，並沒有涉及到記憶體佔用方面，也就是說：
Chrome 佔用記憶體可能還是跟現在一樣的大小，但是速度變快了
。不知道這是一個好訊息還是壞訊息，就好像現在的寬頻資費一樣，價錢不變，但是網速給你提上去。運營商美言：寬頻免費提速，加量不加價。
當然也不排除Chrome 53 的GPU調整和記憶體之間也有見不得人的勾當，畢竟整合顯示卡和記憶體的關係也是千絲萬縷，離開誰也活不了啊。
另外，這次效能的提升和 V8引擎沒有啥關係啊，所以大家不要嘀咕 Node。js 會不會因此變得更美好了啦。。
如果你看到這裡，已經迫不及待的想要嘗試 Chrome 53 了， 它就在這裡：Chrome Canary ，鑑於大家都是 chromer，翻牆這種小事你自己搞定啦~~
如果你想檢視更多細節上的資訊，可以點開整個評測文件： Google Doc，為了方便，我已經貼上了更詳細的多平臺對比 ，玩兒的開心：）
# Chrome 53 在 Mac 上的總體表現：
細節表現：
# 最新版的 Safari 技術預覽版 與 Chrome 的對比：
細節表現：
＃在移動端 iOS 9.3. iPad Air 2 裝置 與搭載Android M 系統的 Pixel C （某平版電腦）之間的對比 ，但需要注意的是因為硬體引數有很多不同，測試資料所以不太有說服力。
細節表現：
# 在安卓平版上：
細節表現：
以上是全部資料統計。
或許你已經被 chrome 的記憶體佔用折磨的苦不堪言，早已逃離 chrome 多年，當你看完chrome53恐怖的提升程度後，或許你會小小的嘗試一下改變 ：）
另外，因為沒有chrome53記憶體佔用的資料對比，所以我們可以隨便猜測， 哈哈。
易旭昕2016-06-22 16:19:16看起來主要是來自GPU光柵化的效能提升，GPU光柵化作為一個實驗特性其實存在很久了，一開始是Chrome for Android上啟用，後來是Android WebView上啟用，現在看來Mac上面也應用上了。
早期GPU光柵化的開啟有較多限制（起碼M50還是這個樣子）：
1，首先是隻針對移動版網頁；
2，其次要求網頁沒有太複雜的路徑繪製和SVG；
這個限制主要來自於Skia GPU庫對文字的繪製和複雜路徑的繪製仍然需要使用CPU光柵化來輔助，所以這型別網頁使用GPU光柵化的效能比CPU光柵化來的更差。從文中的資訊看來Skia GPU庫應該解決了這些問題，包含SVG的網頁也可以使用GPU光柵化，並且效能提升明顯。
GPU光柵化的確會帶來一部分的記憶體增加，主要來自於點陣圖需要上傳成紋理加上其它的一些額外的GPU資源，Chromium目前設定的點陣圖紋理快取池上限好像是96M，對於移動裝置還是有些影響的。不過Chromium當前也有記憶體最佳化的專項透過其它方式減少記憶體佔用，所以兩相抵消後應該不會有太大差別。
除了GPU光柵化外，針對CSS/JS動畫，JS事件響應時間，核心排版耗時最佳化的專案還有：
1，Blink Scheduler - 新的核心任務排程器，主要是透過任務優先順序佇列和搶佔式優先順序排程來加快高優先順序任務的響應；
2，Slimming Paint - Blink 核心和合成器之間的繪圖相關介面的重構，減少 Blink 核心排版的開銷，最佳化網頁圖層化的策略（類似的設計在Firefox應該已經使用一段時間了）；
3，GPU Scheduler - 作用類似 1，用於改進 GPU 任務的排程，比如合成任務優先順序會高於光柵化任務；
年初的時候寫過一個PPT在部門內介紹過Chromium渲染的一些基本概念和上述改進，供參考（當時是針對早期版本寫的，所以有些資訊已經過時了）：
Page Rendering
（
Page Rendering - Main Frame and Impl Frame
）
韋易笑2016-07-31 13:37:21坐等 atom和 electron的效能大幅度提升。
