共计 7175 个字符，预计需要花费 18 分钟才能阅读完成。
本文首发于微信公众号：大迁世界, 我的微信：qq449245884，我会第一工夫和你分享前端行业趋势，学习路径等等。
更多开源作品请看 GitHub https://github.com/qq449245884/xiaozhi，蕴含一线大厂面试残缺考点、材料以及我的系列文章。
快来收费体验 ChatGpt plus 版本的，咱们出的钱
体验地址:https://chat.waixingyun.cn
能够退出网站底部技术群，一起找 bug.
该系列是由 @marvinhagemeist 撰写的，旨在通过一系列文章减速 JavaScript 生态系统。这些文章提供了无关如何减速 JavaScript 生态系统的有用信息。文章涵盖了各种主题，包含 PostCSS、SVGO、模块解析、eslint 和 npm 脚本。
明天咱们来看第一局部。在第一局部文章 [1] 中，作者分享了许多风行库的减速技巧。作者倡议防止不必要的类型转换，防止在函数外部创立函数等。
只管趋势仿佛是将每个 JavaScript 构建工具重写为其余语言，如 Rust 或 Go，但以后基于 JavaScript 的工具能够更快。典型前端我的项目中的构建流水线通常由许多不同的工具组成。然而，工具的多样化使得工具维护者更难以发现性能问题，因为他们须要晓得本人的工具通常与哪些工具一起应用。
从纯语言角度来看，JavaScript 必定比 Rust 或 Go 慢，但以后的 JavaScript 工具能够失去相当大的改良。当然，JavaScript 比较慢，但与明天相比，它不应该那么慢。JIT 引擎当初十分快！
在 PostCSS 中节俭了 4.6 秒
有一个十分有用的插件叫做 postcss-custom-properties，它在旧版浏览器中减少了对 CSS 自定义属性的根本反对。不知何故，它在跟踪中十分突出，被归因于它外部应用的单个正则表达式，导致了高达 4.6 秒的老本。这看起来很奇怪。
正则表达式看起来很像搜寻特定正文值以更改插件行为的内容，相似于 eslint 中用于禁用特定 linting 规定的内容。尽管在 README 中没有提到，然而查看源代码确认了这一假如。
创立正则表达式的地位是函数的一部分，该函数查看 CSS 规定或申明是否由该正文前置。
function isBlockIgnored(ruleOrDeclaration) {
const rule = ruleOrDeclaration.selector
? ruleOrDeclaration
: ruleOrDeclaration.parent;
return /(!\s*)?postcss-custom-properties:\s*off\b/i.test(rule.toString());
}rule.toString() 调用很快引起了我的留神。如果你正在解决性能问题，那么将一种类型转换为另一种类型的中央通常值得再次查看，因为不用进行转换总是能够节省时间的。在这种状况下乏味的是，rule 变量始终蕴含具备自定义 toString 办法的 object。它从未是一个字符串，因而咱们晓得咱们总是要领取肯定的序列化老本来测试正则表达式。从教训上讲，我晓得将正则表达式与许多短字符串匹配比将其与大量长字符串匹配要慢得多。这是一个期待优化的次要候选项！
这段代码令人不安的一点是，每个输出文件都必须领取这个老本，无论它是否有 postcss 正文。咱们晓得，在长字符串上运行一个正则表达式比在短字符串上反复运行正则表达式和序列化老本更便宜，因而，如果咱们晓得文件不蕴含任何 postcss 正文，咱们能够爱护此函数，防止甚至不用调用 isBlockIgnored。
利用了修复后，构建工夫惊人地缩小了 4.6 秒！
优化 SVG 压缩速度
接下来是 SVGO，一个用于压缩 SVG 文件的库。它十分棒，是领有大量 SVG 图标我的项目的基石。CPU 剖析显示，破费了 3.1 秒来压缩 SVG 文件。咱们能放慢这个过程吗？
在剖析数据时，有一个函数引起了留神：strongRound。更重要的是，该函数总是紧随着一小段垃圾回收清理（请参见小红框）。
查看源代码
/**
* Decrease accuracy of floating-point numbers
* in path data keeping a specified number of decimals.
* Smart rounds values like 2.3491 to 2.35 instead of 2.349.
*/
function strongRound(data: number[]) {for (var i = data.length; i-- > 0;) {if (data[i].toFixed(precision) != data[i]) {var rounded = +data[i].toFixed(precision - 1);
data[i] =
+Math.abs(rounded - data[i]).toFixed(precision + 1) >= error
? +data[i].toFixed(precision)
: rounded;
}
}
return data;
}这是一个用于压缩数字的函数，在任何典型的 SVG 文件中都有很多数字。该函数接管一个 numbers 数组，并冀望扭转其条目。让咱们看一下其实现中应用的变量类型。通过仔细检查，咱们留神到在字符串和数字之间来回转换了很屡次。
function strongRound(data: number[]) {for (var i = data.length; i-- > 0;) {
// Comparison between string and number -> string is cast to number
if (data[i].toFixed(precision) != data[i]) {
// Creating a string from a number that's casted immediately
// back to a number
var rounded = +data[i].toFixed(precision - 1);
data[i] =
// Another number that is casted to a string and directly back
// to a number again
+Math.abs(rounded - data[i]).toFixed(precision + 1) >= error
? // This is the same value as in the if-condition before,
// just casted to a number again
+data[i].toFixed(precision)
: rounded;
}
}
return data;
}四舍五入数字仿佛是一件只须要进行一点点数学运算就能实现的事件，而不用将数字转换为字符串。通常状况下，优化的关键在于用数字表白事物，次要起因是 CPU 在解决数字方面十分杰出。通过一些渺小的扭转，咱们能够确保始终处于数字畛域，从而完全避免字符串转换。
// Does the same as `Number.prototype.toFixed` but without casting
// the return value to a string.
function toFixed(num, precision) {
const pow = 10 ** precision;
return Math.round(num * pow) / pow;
}
// Rewritten to get rid of all the string casting and call our own
// toFixed() function instead.
function strongRound(data: number[]) {for (let i = data.length; i-- > 0;) {const fixed = toFixed(data[i], precision);
// Look ma, we can now use a strict equality comparison!
if (fixed !== data[i]) {const rounded = toFixed(data[i], precision - 1);
data[i] =
toFixed(Math.abs(rounded - data[i]), precision + 1) >= error
? fixed // We can now reuse the earlier value here
: rounded;
}
}
return data;
}再次运行剖析，确认咱们可能将构建工夫减速约 1.4 秒！
短字符串上的正则表达式（第二局部）
在 strongRound 的严密邻近，另一个性能看起来很可疑，因为它须要近乎一秒钟（0.9 秒）能力实现。
相似于 stringRound，此函数也能够压缩数字，但有一个额定的技巧，即如果数字有小数并且小于 1 且大于-1，则能够删除前导零。因而，0.5 能够压缩为 .5，-0.2 别离能够压缩为 -.2。特地是最初一行看起来很乏味。
const stringifyNumber = (number: number, precision: number) => {
// ...snip
// remove zero whole from decimal number
return number.toString().replace(/^0\./, ".").replace(/^-0\./, "-.");
};在这里，咱们将一个数字转换为字符串并对其调用正则表达式。数字的字符串版本很可能是一个短字符串。咱们晓得一个数字不能同时是 n > 0 && n < 1 和 n > -1 && n < 0。甚至 NaN 也没有这个能力！从中咱们能够推断出，只有一个正则表达式匹配或者两个都不匹配，但永远不会同时匹配。至多 .replace 中的一个调用总是节约的。
咱们能够通过手动辨别这些状况来进行优化。只有当咱们晓得咱们正在解决一个具备前导 0 的数字时，咱们才利用咱们的替换逻辑。这些数字查看比进行正则表达式搜寻更快。
const stringifyNumber = (number: number, precision: number) => {
// ...snip
// remove zero whole from decimal number
const strNum = number.toString();
// Use simple number checks
if (0 < num && num < 1) {return strNum.replace(/^0\./, ".");
} else if (-1 < num && num < 0) {return strNum.replace(/^-0\./, "-.");
}
return strNum;
};咱们能够更进一步，齐全解脱正则表达式搜寻，因为咱们能够百分之百确定字符串中前导 0 的地位，因而能够间接操作字符串。
const stringifyNumber = (number: number, precision: number) => {
// ...snip
// remove zero whole from decimal number
const strNum = number.toString();
if (0 < num && num < 1) {
// Plain string processing is all we need
return strNum.slice(1);
} else if (-1 < num && num < 0) {
// Plain string processing is all we need
return "-" + strNum.slice(2);
}
return strNum;
};因为 svgo 代码库中曾经有一个独自的函数来修剪前导 0，咱们能够利用它来实现。又节俭了 0.9 秒！
内联函数、内联缓存和递归
一个名为 monkeys 的函数仅凭其名称就引起了我的趣味。在跟踪中，我能够看到它在本身外部被屡次调用，这是某种递归产生的强烈批示。它常常用于遍历相似树形构造的数据。每当应用某种遍历时，就有可能它在代码的“热”门路中。尽管这并非所有状况都成立，但在我的教训中，这是一个不错的教训法令。
function perItem(data, info, plugin, params, reverse) {function monkeys(items) {items.children = items.children.filter(function (item) {
// reverse pass
if (reverse && item.children) {monkeys(item);
}
// main filter
let kept = true;
if (plugin.active) {kept = plugin.fn(item, params, info) !== false;
}
// direct pass
if (!reverse && item.children) {monkeys(item);
}
return kept;
});
return items;
}
return monkeys(data);
}这里咱们有一个函数，它在其主体内创立另一个函数，该函数再次调用外部函数。如果我必须猜想，我会认为这是为了节俭一些按键次数而在此处实现的，而不用再次传递所有参数。问题是，当内部函数频繁调用时，外部函数中创立的函数很难进行优化。
function perItem(items, info, plugin, params, reverse) {items.children = items.children.filter(function (item) {
// reverse pass
if (reverse && item.children) {perItem(item, info, plugin, params, reverse);
}
// main filter
let kept = true;
if (plugin.active) {kept = plugin.fn(item, params, info) !== false;
}
// direct pass
if (!reverse && item.children) {perItem(item, info, plugin, params, reverse);
}
return kept;
});
return items;
}咱们能够通过始终明确传递所有参数而不是像以前那样通过闭包捕捉它们来解脱外部函数。这种变动的影响相当小，但总共节俭了另外 0.8 秒。
侥幸的是，这曾经在新的次要 3.0.0 版本中失去解决，但须要一些工夫能力使生态系统切换到新版本。
当心 for…of 转译
一个简直雷同的问题产生在 @vanilla-extract/css 中。公布的软件包附带以下代码片段：
class ConditionalRuleset {getSortedRuleset() {
//...
var _loop = function _loop(query, dependents) {doSomething();
};
for (var [query, dependents] of this.precedenceLookup.entries()) {_loop(query, dependents);
}
//...
}
}这个函数乏味的中央在于它在原始源代码中并不存在。在原始源代码中，它是一个规范的 for...of 循环。
class ConditionalRuleset {getSortedRuleset() {
//...
for (var [query, dependents] of this.precedenceLookup.entries()) {doSomething();
}
//...
}
}我无奈在 Babel 或 TypeScript 的 REPL 中复制此问题，但我能够确认它是由它们的构建流程引入的。鉴于它仿佛是构建工具上的共享形象，我会假如还有其余几个我的项目受到了影响。因而，当初我只是在 node_modules 中本地修补了该软件包，并很快乐看到这进一步提高了构建工夫 0.9s。
语义化版本号、案例
对于这个问题，我不确定是否配置有误。基本上，该配置文件显示每当它转换文件时，整个 Babel 配置都会被从新读取。
在截图中有点难看分明，但其中一个占用大量工夫的性能是来自 semver 包的代码，这个包也是 npm 的 cli 中应用的包。嗯？semver 与 babel 有什么关系？直到一段时间后我才明确：它是用于解析 @babel/preset-env 的 browserlist 指标的。尽管 browserlist 设置可能看起来相当简短，但最终它们被扩大为大概 290 个独自的指标。
仅仅这些还不足以引起关注，但在应用验证函数时很容易疏忽调配老本。这在 babel 的代码库中有点扩散，但基本上浏览器指标的版本被转换为 semver 字符串 "10" -> "10.0.0"，而后进行验证。其中一些版本号曾经匹配了 semver 格局。这些版本号和有时版本范畴会互相比拟，直到找到咱们须要转码的最低公共功能集。这种办法没有任何问题。
性能问题在这里呈现，因为 semver 版本被存储为 string 而不是解析后的 semver 数据类型。这意味着每次调用 semver.valid('1.2.3') 都会创立一个新的 semver 实例并立刻销毁它。当应用字符串比拟 semver 版本时，状况也是如此： semver.lt('1.2.3', '9.8.7')。这就是为什么咱们在跟踪中常常看到 semver 的起因。
通过在 node_modules 中再次进行本地修补，我可能将构建工夫再次缩短 4.7s。
代码部署后可能存在的 BUG 没法实时晓得，预先为了解决这些 BUG，花了大量的工夫进行 log 调试，这边顺便给大家举荐一个好用的 BUG 监控工具 Fundebug。
交换
有幻想，有干货，微信搜寻 【大迁世界】 关注这个在凌晨还在刷碗的刷碗智。
本文 GitHub https://github.com/qq449245884/xiaozhi 已收录，有一线大厂面试残缺考点、材料以及我的系列文章。
