小编not*_*nja的帖子

在 Node https 模块文档中，关于 https.request，显示了一个示例：

const options = {
  hostname: 'encrypted.google.com',
  port: 443,
  path: '/',
  method: 'GET',
  key: fs.readFileSync('test/fixtures/keys/agent2-key.pem'),
  cert: fs.readFileSync('test/fixtures/keys/agent2-cert.pem')
};
options.agent = new https.Agent(options);

const req = https.request(options, (res) => {
  // ...
});

在我看来，这个例子有点模棱两可，我已经问过一个关于这种歧义的问题，并在评论重申奇怪的措辞之后，为此打开了一个问题。

无论如何，我仍然试图了解代理在这种情况下扮演的角色，因为 https.Agent 模块确实接受了 TLS 连接选项：

interface AgentOptions extends http.AgentOptions, tls.ConnectionOptions

https.Agent对象的定义是：

类似于 http.Agent 的 HTTPS 代理对象。

http.Agent对象的定义是：

代理负责管理 HTTP 客户端的连接持久性和重用。

由此我了解到，代理“负责”管理连接——显然，https.Agent 存在于“普通”http.Agent 之上的事实意味着它“负责”管理一个连接HTTPS 连接 - 因此它可能会收到 TLS 配置选项。

我的问题是 - 这是否意味着在这种情况下代理有额外的责任配置请求的网络安全？如果这是真的，这是一个奇怪的 API - 我本来希望在 https.request 的单独密钥上看到网络连接配置（如上面代码段后面的示例所示）。为什么要为另一个责任重载同一个对象？真的，为什么要使用 …

这个要点是我写的一个小型基准测试，用于比较JS中深度为 1 的扁平数组的 4 种替代方案的性能 （代码可以按原样复制到谷歌控制台）。如果我没有遗漏任何东西，那么本机 Array.prototype.flat 迄今为止的性能最差 - 比任何替代品慢 30-50 倍。

更新：我在jsperf上创建了一个基准。

应该注意的是，该基准测试中的第 4 次实现始终是性能最高的 - 通常实现 70 倍的性能。该代码在 node v12 和 Chrome 控制台中进行了多次测试。

这个结果在一个大的子集中最为突出 - 请参阅下面测试的最后 2 个数组。考虑到规范和似乎完全遵循规范的V8 实现，这个结果非常令人惊讶。我的 C++ 知识不存在，因为我对 V8 兔子洞很熟悉，但在我看来，鉴于递归定义，一旦我们到达最终深度子数组，就不会对该子数组调用进行进一步的递归调用（标志当递减的深度达到 0 时，shouldFlatten 为假，即最终的子级别）并且添加到扁平结果包括迭代循环每个子元素，以及对该方法的简单调用。因此，我看不出为什么 a.flat 应该在性能上受到如此大的影响。

我想也许在原生公寓中结果的大小没有预先分配的事实可能解释了这种差异。此基准测试中的第二个实现（未预先分配）表明，仅凭这一点无法解释差异 - 它的性能仍然是原生 flat 的 5-10 倍。这可能是什么原因？

已测试的实现（代码中的顺序相同，存储在 implementations 数组中 - 我写的两个在代码片段的末尾）：

1. 我自己的展平实现包括预先分配最终展平的长度（从而避免所有重新分配的大小）。原谅命令式风格的代码，我是为了最大的性能。
2. 最简单的实现，循环遍历每个子数组并推入最终数组。（因此冒着许多大小重新分配的风险）。
3. Array.prototype.flat（原生平面）
4. [ ].concat(...arr)（=展开数组，然后将结果连接在一起。这是一种实现深度=1 展平的流行方法）。

测试的数组（代码中的顺序相同，存储在 benchmarks 对象中）：

1. 1000 个子数组，每个子数组 10 个元素。（共10人）
2. 10 个子数组，每个子数组 …