怎么做网站例如京东,wordpress主题 餐饮,电子商务就业方向,哈尔滨城乡建设厅网站1. 引言 本周精读的文章是 V8 引擎 Lazy Parsing#xff0c;看看 V8 引擎为了优化性能#xff0c;做了怎样的尝试吧#xff01; 这篇文章介绍的优化技术叫 preparser#xff0c;是通过跳过不必要函数编译的方式优化性能。 2. 概述 精读 解析 Js 发生在网页运行的关键…1. 引言 本周精读的文章是 V8 引擎 Lazy Parsing看看 V8 引擎为了优化性能做了怎样的尝试吧 这篇文章介绍的优化技术叫 preparser是通过跳过不必要函数编译的方式优化性能。 2. 概述 精读 解析 Js 发生在网页运行的关键路径上因此加速对 JS 的解析就可以加速网页运行效率。 然而并不是所有 Js 都需要在初始化时就被执行因此也不需要在初始化时就解析所有的 Js因为编译 Js 会带来三个成本问题 编译不必要的代码会占用 CPU 资源。在 GC 前会占用不必要的内存空间。编译后的代码会缓存在磁盘占用磁盘空间。因此所有主流浏览器都实现了 Lazy Parsing延迟解析它会将不必要的函数进行预解析也就是只解析出外部函数需要的内容而全量解析在调用这个函数时才发生。 预解析的挑战 本来预解析也不难因为只要判断一个函数是否会立即执行就可以了只有立即执行的函数才需要被完全解析。 使得预解析变复杂的是变量分配问题。原文通过了堆栈调用的例子说明原因 Js 代码的执行在堆栈上完成比如下面这个函数 function f(a, b) {const c a b;return c;
}function g() {return f(1, 2);// The return instruction pointer of f now points here// (because when f returns, it returns here).
} 这段函数的调用堆栈如下 首先是全局 This globalThis然后执行到函数 f再对 a b 进行赋值。在执行 f 函数时通过 rip g(return instruction pointer) 保存 g 堆栈状态再保存堆栈跳出后返回位置的指针 save fp(frame pointer)最后对变量 c 赋值。 这看上去没有问题只要将值存在堆栈就搞定了。但是将变量定义到函数内部就不一样了 function make_f(d) {// ← declaration of dreturn function inner(a, b) {const c a b d; // ← reference to dreturn c;};
}const f make_f(10);function g() {return f(1, 2);
} 将变量 d 申明在函数 make_f 中且在返回函数 inner 中用到了 d。那么函数的调用栈就变成了这样 需要创建一个 context 存储函数 f 中变量 d 的值。 也就是说如果一个在函数内部定义的变量被子 Scope 使用时Js 引擎需要识别这种情况并将这个变量值存储在 context 中。 所以对于函数定义的每一个入参我们需要知道其是否会被子函数引用。也就是说在 preparser 阶段我们只要少能分析出哪些变量被内部函数引用了。 难以分辨的引用 预处理器中跟踪变量的申明与引用很复杂因为 Js 的语法导致了无法从部分表达式推断含义比如下面的函数 function f(d) {function g() {const a ({ d } 我们不清楚第三行的 d 到底是不是指代第一行的 d。它可能是 function f(d) {function g() {const a ({ d } { d: 42 });return a;}return g;
} 也可能只是一个自定义函数参数与上面的 d 无关 function f(d) {function g() {const a ({ d }) d;return a;}return [d, g];
} 惰性 parse 在执行函数时只会将最外层执行的函数完全编译并生成 AST而对内部模块只进行 preparser。 // This is the top-level scope.
function outer() {// preparsedfunction inner() {// preparsed}
}outer(); // Fully parses and compiles outer, but not inner. 为了允许惰性编译函数上下文指针指向了 ScopeInfo 的对象从代码中可以看到ScopeInfo 包含上下文信息比如当前上下文是否有函数名是否在一个函数内等等当编译内部函数时可以利用 ScopeInfo 继续编译子函数。 但是为了判断惰性编译函数自身是否需要一个上下文我们需要再次解析内部的函数比如我们需要知道某个子函数是否对外层函数定义的变量有所引用。 这样就会产生递归遍历 由于代码总会包含一些嵌套而编译工具更会产生 IIFE(立即调用函数) 这种多层嵌套的表达式使得递归性能比较差。 而下面有一种办法可以将时间复杂度简化为线性将变量分配的位置序列化为一个密集的数组当惰性解析函数时变量会按照原先的顺序重新创建这样就不需要因为子函数可能引用外层定义变量的原因对所有子函数进行递归惰性解析了。 按照这种方式优化后的时间复杂度是线性的 针对模块化打包的优化 由于现代代码几乎都是模块化编写的构建起在打包时会将模块化代码封装在 IIFE立即调用的闭包中以保证模拟模块化环境运行。比如 (function(){....})()。 这些代码看似在函数中应该惰性编译但其实这些模块化代码从一开始就要被编译否则反而会影响性能因此 V8 有两种机制识别这些可能被立即调用的函数 如果函数是带括号的比如 (function(){...})就假设它会被立即调用。从 V8 v5.7 / Chrome 57 开始还会识别 uglifyJS 的 !function(){...}(), function(){...}(), function(){...}() 这种模式。然而在浏览器引擎解析环境比较复杂很难对函数进行完整字符串匹配因此只能对函数头进行简单判断。所以对于下面这种匿名函数的行为浏览器是不识别的 // pre-parser
function run(func) {func()
}run(function(){}) // 在这执行它进行 full parser 上面的代码看上去没毛病但由于浏览器只检测被括号括住的函数因此这个函数不被认为是立即执行函数因此在后续执行时会被重复 full-parse。 也有一些代码辅助转换工具帮助 V8 正确识别比如 optimize-js会将代码做如下转换。 转换前 !function (){}()
function runIt(fun){ fun() }
runIt(function (){}) 转换后 !(function (){})()
function runIt(fun){ fun() }
runIt((function (){})) 然而在 V8 v7.5 已经很大程度解决了这个问题因此现在其实不需要使用 optimize-js 这种库了 4. 总结 JS 解析引擎在性能优化做了不少工作但同时也要应对代码编译器产生的特殊 IIFE 闭包防止对这种立即执行闭包进行重复 parser。 最后不要试图总是将函数用括号括起来因为这样会导致惰性编译的特性无法启用。 讨论地址是精读《V8 引擎 Lazy Parsing》 · Issue #148 · dt-fe/weekly 如果你想参与讨论请 点击这里每周都有新的主题周末或周一发布。前端精读 - 帮你筛选靠谱的内容。 关注 前端精读微信公众号 special Sponsors DevOps 全流程平台 版权声明自由转载-非商用-非衍生-保持署名创意共享 3.0 许可证 转载于:https://www.cnblogs.com/ascoders/p/10752180.html
