[Chromium官方博客文章转载]Jank Busters Part One(UI Jank指的是界面来不及刷新导致的卡塞空白现象?
2015-11-01 15:40
519 查看
Jank Busters
Part One
Planet Chromium by Michael Hablich / 1d
// keep unread //
hide // preview
Jank, or in other words visible stutters, can be noticed when Chrome fails to render a frame within 16.66ms (disrupting 60 frames per second motion). As of today most of the V8 garbage collection work is performed on the main rendering thread, c.f. Figure 1,
often resulting in jank when too many objects need to be maintained. Eliminating jank has always been a high priority for the V8 team [1,2,
3]. In this blog post we will discuss a few optimizations that were implemented between M41 and M46 which significantly reduce garbage collection pauses resulting in better user experience.
A major source of jank during garbage collection is processing various bookkeeping data structures. Many of these data structures enable optimizations that are unrelated to garbage collection. Two examples are the list of all ArrayBuffers, and each ArrayBuffer’s
list of views. These lists allow for an efficient implementation of the DetachArrayBuffer operation without imposing any performance hit on access to an ArrayBuffer view. In situations, however, where a web page creates millions of ArrayBuffers, (e.g., WebGL-based
games), updating those lists during garbage collection causes significant jank. In M46, we removed these lists and instead detect detached buffers by inserting checks before every load and store to ArrayBuffers. This amortizes the cost of walking the big bookkeeping
list during GC by spreading it throughout program execution resulting in less jank. Although the per-access checks can theoretically slow down the throughput of programs that heavily use ArrayBuffers, in practice V8's optimizing compiler can often remove redundant
checks and hoist remaining checks out of loops, resulting in a much smoother execution profile with little or no overall performance penalty.
Another source of jank is the bookkeeping associated with tracking the lifetimes of objects shared between Chrome and V8. Although the Chrome and V8 memory heaps are distinct, they must be synchronized for certain objects, like DOM nodes, that are implemented
in Chrome's C++ code but accessible%0WebGL functions that are known to usually take small arrays as parameters the underlying data is copied on the stack, making a global reference obsolete. The result of such a mixed approach is a reduction ofr>Figure 2:
Some garbage collection operations performed on the concurrent garbage collection threads.
The impact of the discussed optimizations is clearly visible in WebGL-based games, for example
Turbolenz' Oort Online demo. The following video compares Chrome M41 to M46
We are currently in the process of making more garbage collection components incremental, concurrent, and parallel, to shrink garbage collection pause times on the main thread even further. Stay tuned as we have0we implemented concurrent unmapping of unused
pages to reduce the work that has to be performed on the main thread, c.f. Figure 2.
The impact of the discussed optimizations is clearly visible in WebGL-based games, for example
Turbolenz' Oort Online demo. The following video compares Chrome M41 to M46
We are currently in the process of making more garbage collection components incremental, concurrent, and parallel, to shrink garbage collection pause times on the main thread even further. Stay tuned as we have some interesting patches in the pipeline.
Posted by the jank busters: Jochen Eisinger, Michael Lippautz, and Hannes Payer
Part One
Planet Chromium by Michael Hablich / 1d
// keep unread //
hide // preview
Jank, or in other words visible stutters, can be noticed when Chrome fails to render a frame within 16.66ms (disrupting 60 frames per second motion). As of today most of the V8 garbage collection work is performed on the main rendering thread, c.f. Figure 1,
often resulting in jank when too many objects need to be maintained. Eliminating jank has always been a high priority for the V8 team [1,2,
3]. In this blog post we will discuss a few optimizations that were implemented between M41 and M46 which significantly reduce garbage collection pauses resulting in better user experience.
Figure 1: Garbage collection performed on the main thread. |
list of views. These lists allow for an efficient implementation of the DetachArrayBuffer operation without imposing any performance hit on access to an ArrayBuffer view. In situations, however, where a web page creates millions of ArrayBuffers, (e.g., WebGL-based
games), updating those lists during garbage collection causes significant jank. In M46, we removed these lists and instead detect detached buffers by inserting checks before every load and store to ArrayBuffers. This amortizes the cost of walking the big bookkeeping
list during GC by spreading it throughout program execution resulting in less jank. Although the per-access checks can theoretically slow down the throughput of programs that heavily use ArrayBuffers, in practice V8's optimizing compiler can often remove redundant
checks and hoist remaining checks out of loops, resulting in a much smoother execution profile with little or no overall performance penalty.
Another source of jank is the bookkeeping associated with tracking the lifetimes of objects shared between Chrome and V8. Although the Chrome and V8 memory heaps are distinct, they must be synchronized for certain objects, like DOM nodes, that are implemented
in Chrome's C++ code but accessible%0WebGL functions that are known to usually take small arrays as parameters the underlying data is copied on the stack, making a global reference obsolete. The result of such a mixed approach is a reduction ofr>Figure 2:
Some garbage collection operations performed on the concurrent garbage collection threads.
The impact of the discussed optimizations is clearly visible in WebGL-based games, for example
Turbolenz' Oort Online demo. The following video compares Chrome M41 to M46
We are currently in the process of making more garbage collection components incremental, concurrent, and parallel, to shrink garbage collection pause times on the main thread even further. Stay tuned as we have0we implemented concurrent unmapping of unused
pages to reduce the work that has to be performed on the main thread, c.f. Figure 2.
Figure 2: Some garbage collection operations performed on the concurrent garbage collection threads. |
Turbolenz' Oort Online demo. The following video compares Chrome M41 to M46
We are currently in the process of making more garbage collection components incremental, concurrent, and parallel, to shrink garbage collection pause times on the main thread even further. Stay tuned as we have some interesting patches in the pipeline.
Posted by the jank busters: Jochen Eisinger, Michael Lippautz, and Hannes Payer
相关文章推荐
- Android Manifest 用法
- Android学习笔记(二九):嵌入浏览器
- 超过 77% 的桌面计算机运行基于 Chromium 的浏览器
- 微软发布令牌漏洞公告:可绕过 Chromium 沙盒执行任意代码
- 峰回路转,Firefox 浏览器即将重返 iOS 平台
- 峰回路转,Firefox 浏览器即将重返 iOS 平台
- Linux 自检和 SystemTap
- 浏览器 cookie 限制
- 玩转浏览器IE7的5个顶级使用技巧
- 字符集导致的浏览器跨站脚本攻击分析
- 更改IE浏览器的图标
- 如何创建ajax对象并兼容多个浏览器
- css ie6 ie7 ff的CSS hack使用技巧
- CSS 浏览器的等宽空格问题解决
- 区分IE6,IE7,firefox的CSS hack
- PHP限制页面只能在微信自带浏览器访问的代码
- ASP.NET实现推送文件到浏览器的方法
- 多种浏览器清除缓存的方法小结
- Dom与浏览器兼容性说明
- firefox(火狐)和ie浏览器禁止右键和禁止复制的代码