function compareByGeneratedPositionsDeflated(mappingA, mappingB, onlyCompareGenerated) {var cmp = mappingA.generatedLine - mappingB.generatedLine;if (cmp !== 0) {return cmp;}cmp = mappingA.generatedColumn - mappingB.generatedColumn;if (cmp !== 0 || onlyCompareGenerated) {return cmp;}cmp = strcmp(mappingA.source, mappingB.source);if (cmp !== 0) {return cmp;}cmp = mappingA.originalLine - mappingB.originalLine;if (cmp !== 0) {return cmp;}cmp = mappingA.originalColumn - mappingB.originalColumn;if (cmp !== 0) {return cmp;}return strcmp(mappingA.name, mappingB.name);
}

这里我们首先比较 generatedLine 的映射。一般对比原始的源文件，可能会生成更多的行，所以将 generatedMappings 分成多个单独的数组是没有意义的。

但是，当我看到解析代码时，我注意到了以下的内容：

while (index < length) {if (aStr.charAt(index) === ';') {generatedLine++;// ...} else if (aStr.charAt(index) === ',') {// ...} else {mapping = new Mapping();mapping.generatedLine = generatedLine;// ...}
}

let subarrayStart = 0;
while (index < length) {if (aStr.charAt(index) === ';') {generatedLine++;// ...// Sort subarray [subarrayStart, generatedMappings.length].sortGenerated(generatedMappings, subarrayStart);subarrayStart = generatedMappings.length;} else if (aStr.charAt(index) === ',') {// ...} else {mapping = new Mapping();mapping.generatedLine = generatedLine;// ...}
}
// Sort the tail.
sortGenerated(generatedMappings, subarrayStart);

const compareGenerated = util.compareByGeneratedPositionsDeflatedNoLine;function sortGenerated(array, start) {let l = array.length;let n = array.length - start;if (n <= 1) {return;} else if (n == 2) {let a = array[start];let b = array[start + 1];if (compareGenerated(a, b) > 0) {array[start] = b;array[start + 1] = a;}} else if (n < 20) {for (let i = start; i < l; i++) {for (let j = i; j > start; j--) {let a = array[j - 1];let b = array[j];if (compareGenerated(a, b) <= 0) {break;}array[j - 1] = b;array[j] = a;}}} else {quickSort(array, compareGenerated, start);}
}

排序时间急剧下降，而解析时间稍微增加 — 这是因为代码将 generatedMappings 作为解析循环的一部分进行排序，使得我们的分解略显无意义。让我们对比下改善总时间（解析和排序一起）。

改善总时间

function Mapping(memory) {this._memory = memory;this.pointer = 0;
}
Mapping.prototype = {get generatedLine () {return this._memory[this.pointer + 0];},get generatedColumn () {return this._memory[this.pointer + 1];},get source () {return this._memory[this.pointer + 2];},get originalLine () {return this._memory[this.pointer + 3];},get originalColumn () {return this._memory[this.pointer + 4];},get name () {return this._memory[this.pointer + 5];},set generatedLine (value) {this._memory[this.pointer + 0] = value;},set generatedColumn (value) {this._memory[this.pointer + 1] = value;},set source (value) {this._memory[this.pointer + 2] = value;},set originalLine (value) {this._memory[this.pointer + 3] = value;},set originalColumn (value) {this._memory[this.pointer + 4] = value;},set name (value) {this._memory[this.pointer + 5] = value;},
};

然后我调整了解析和排序代码，如下所示：

BasicSourceMapConsumer.prototype._parseMappings = function (aStr, aSourceRoot) {// Allocate 4 MB memory buffer. This can be proportional to aStr size to// save memory for smaller mappings.this._memory = new Int32Array(1 * 1024 * 1024);this._allocationFinger = 0;let mapping = new Mapping(this._memory);// ...while (index < length) {if (aStr.charAt(index) === ';') {// All code that could previously access mappings directly now needs to// access them indirectly though memory.sortGenerated(this._memory, generatedMappings, previousGeneratedLineStart);} else {this._allocateMapping(mapping);// ...// Arrays of mappings now store "pointers" instead of actual mappings.generatedMappings.push(mapping.pointer);if (segmentLength > 1) {// ...originalMappings[currentSource].push(mapping.pointer);}}}// ...for (var i = 0; i < originalMappings.length; i++) {if (originalMappings[i] != null) {quickSort(this._memory, originalMappings[i], util.compareByOriginalPositionsNoSource);}}
};BasicSourceMapConsumer.prototype._allocateMapping = function (mapping) {let start = this._allocationFinger;let end = start + 6;if (end > this._memory.length) {  // Do we need to grow memory buffer?let memory = new Int32Array(this._memory.length * 2);memory.set(this._memory);this._memory = memory;}this._allocationFinger = end;let memory = this._memory;mapping._memory = memory;mapping.pointer = start;mapping.name = 0x7fffffff;  // Instead of null use INT32_MAX.mapping.source = 0x7fffffff;  // Instead of null use INT32_MAX.
};exports.compareByOriginalPositionsNoSource =function (memory, mappingA, mappingB, onlyCompareOriginal) {var cmp = memory[mappingA + 3] - memory[mappingB + 3];  // originalLineif (cmp !== 0) {return cmp;}cmp = memory[mappingA + 4] - memory[mappingB + 4];  // originalColumnif (cmp !== 0 || onlyCompareOriginal) {return cmp;}cmp = memory[mappingA + 1] - memory[mappingB + 1];  // generatedColumnif (cmp !== 0) {return cmp;}cmp = memory[mappingA + 0] - memory[mappingB + 0];  // generatedLineif (cmp !== 0) {return cmp;}return memory[mappingA + 5] - memory[mappingB + 5];  // name
};

需要我们重写 source-map，直接使用类型数组解析映射而不再使用 JavaScript 的字符串方法 JSON.decode 进行解析。我没有做过这样的改写，但我想应该没有什么问题。

对基线的总体改进

这是开始的情况：

$ d8 bench-shell-bindings.js
...
[Stats samples: 5, total: 24050 ms, mean: 4810 m
s, stddev: 155.91063145276527 ms]
$ sm bench-shell-bindings.js
...
[Stats samples: 7, total: 22925 ms, mean: 3275 ms, stddev: 269.5999093306804 ms]

这是我们完成时的情况：

$ d8 bench-shell-bindings.js
...
[Stats samples: 22, total: 25158 ms, mean: 1143.5454545454545 ms, stddev: 16.59358125226469 ms]
$ sm bench-shell-bindings.js
...
[Stats samples: 31, total: 25247 ms, mean: 814.4193548387096 ms, stddev: 5.591064299397745 ms]

正如你可以看到 WASM+Rust 版本在 SpiderMonkey 上的速度现在增加了大约 15％，而在 V8 上的速度也大致相同。

学习

对于 JavaScript 开发人员

分析器是你的朋友

以各种形式进行分析和性能跟踪是获得高性能的最佳方法。它允许您在代码中放置热点，来揭示运行时的潜在问题。基于这个原因，不要回避使用像 perf 这样的底层分析工具 - “友好”的工具可能不会告诉你整个状况，因为它们隐藏了底层的分析。

不同的性能问题需要不同的方法去分析并能够可视化地去收集分析结果。一定确保您熟悉各种可用的工具。

算法很重要

能够根据抽象复杂性来推理你的代码是一项重要的技能。快速排序一个具有十万个元素的数组好呢？还是快速排序 3333 个数组，每个子数组有 30 元素更好呢？

数学计算可以告诉我们（（100000 log 100000）比（3333 倍的 30 log 30）大 3 倍）- 如果数据量越大，通常能够数学变换就会变得越重要。

除了了解对数之外，你还需要知道一些常识，并且能够评估你的代码在平均和最糟糕的情况下的使用情况：哪些操作很常见，昂贵的运算成本如何摊销，昂贵的运算摊销带来的坏处是什么？

虚拟机也在工作。问题开发者！

不要犹豫，与开发人员讨论奇怪的性能问题。并非所有事情都可以通过改变自己的代码来解决。俄国谚语说道：“制作罐子的不是上帝！”虚拟机开发人员也是人，他们也一样会犯错误。只要把问题理清，他们也相当擅长把这些问题修复。一封邮件或或一个聊天消息或 DM 可能为您节省通过外部 C++ 代码进行调试的时间。

虚拟机仍然需要一点帮助

有时候您也需要编写一些底层代码或者了解一些底层的实现细节，这样有助于挖掘 JavaScript 的最后一丝性能。

人们可能希望有更好的语言级别的工具来实现这一点，但是我们能不能实现还有待观察。

对于语言实现者/设计者

巧妙的优化必须是可检测的

如果您的运行时具有任何内置的智能优化，那么您需要提供一个直观的工具来诊断这些优化失败的时间并向开发人员提供可操作的反馈。

在 JavaScript 这样的语言环境中，至少有像 profiler 这样的分析工具为您单个操作提供一种专业化方法来检测，以确定虚拟机优化的结果是好是坏并且指出原因。

这种排序的自检工具不能依赖于在虚拟机的某个版本上打个特殊的补丁，然后输出一堆毫无可读性的调试结果。相反，它应该是你需要的任何时候，只要打开调试工具窗口，它就能把结果呈现出来。

语言和优化必须是朋友

最后，作为一名语言设计师，您应该尝试预测语言缺乏哪些特性，从而更容易编写出性能良好的代码。市场上的用户是否需要手动设置和管理内存？我确定他们是的。如果大多数人使用了您的语言最后都写出大量性能很低的代码，那就只能通过添加大量的语言特性或者通过其他途径来提升代码的性能。（例如，通过更复杂的优化或请求用户用 Rust 重构代码）

以下是一些语言设计的通用法则：如果要为您的语言添加新特性，请确保运算过程的合理性，而且这些特性很容易被理解和检测。从整个语言层面去考虑优化工作，而不是对一些使用频率很低、性能相对较差的非核心特性去做优化工作。

后记

我们在这篇文章中发现的优化大致分成三个部分：

1. 算法改进；
2. 如何优化完全独立的代码和有潜在依赖关系的代码；
3. 针对 V8 的优化方法。

无论您使用哪种编程语言，都需要考虑到算法性能。当您在本身就“比较慢”的编程语言中使用糟糕的算法时，您能更容易的注意到这一点，但是如果只是换成使用“比较快”的编程语言，还继续使用相同的算法，即使问题会有所缓解，但依然无法从根本上解决问题。这篇文章中的很大一部分内容都致力于这个部分的优化：

• 对子数组排序优化效果要优于对整个数组进行排序优化；
• 讨论使用或者不使用缓存的优缺点。

第二部分是单态性。由于多态性而导致的性能降低不是 V8 特有的问题。这也不是一个 JS 特有的问题。您可以通过不同的实现方式，甚至跨语言的去应用单态。有些语言（Rust，实际上）已经在引擎内为您实现。

最后一个也是最有争议的部分是参数适配问题。

最后，使用映射表示法进行的优化（将单个对象封装到单个类型数组中）横跨了文中提及的三个部分。这是建立在对 GCed 系统的局限性和性能花销，以及 JS 虚拟机作了哪些特殊优化的基础上进行的。

所以... 为什么我选择了这个标题？这是因为我坚信第三部分涉及的问题都会随着时间的推移而被修复。其他部分可通过常用编程语言进行跨语言实现。

很显然，每个开发人员和每个团队都可以自由的去选择，到底是花费 N 小时去分析，阅读和思考他们的 JavaScript 代码，还是花费 M 小时用 X 语言重写他们的东西。

但是：（a）每个人都需要充分意识到这种选择是存在的;（b）语言设计者和实现者应该共同努力使这样的选择越来越不明显 - 也就是说在语言特征和工具方面开展工作，减少“第 3 部分”优化的需求。