性能分析和追踪

追踪

CPU 性能分析或采样性能分析会生成一个配置文件，该配置文件跟踪构建过程中 JavaScript 的执行情况，并可用于识别代码库的各个部分以及构建过程中在其中花费的时间。追踪是一个更高层次的配置文件，它跟踪 Parcel 执行的特定阶段，哪些插件被调用，以及每个阶段花费的时间。

Parcel 追踪可以帮助您通过回答以下问题来优化构建：“构建过程中哪个插件花费的时间最长？” 或“我的项目中哪个文件转换时间最长？”。这些问题用 CPU 采样配置文件提供的数据很难回答，但可以用 Parcel 追踪来回答。

运行追踪的开销相对较小，但并非为零 - 它肯定比在构建过程中运行采样配置文件便宜。特别是，生成的 JSON 文件可能非常大，具体取决于您使用的插件数量和构建的大小。在决定何时启用追踪时，请考虑这些因素。

用法

CLI

要使用 CLI 生成追踪，请使用 --trace CLI 参数启动 Parcel。Parcel 将在您的项目根目录中生成一个追踪 JSON 文件。Parcel 将在构建开始时记录它正在写入追踪的的文件名。

API

要使用 API 生成追踪，您必须在 Parcel 选项中传递 shouldTrace: true 以启用追踪事件。此外，您需要通过 additionalReporters 添加追踪报告器，才能让 Parcel 创建追踪 JSON 文件。例如

import {Parcel} from '@parcel/core';

let bundler = new Parcel({
  // ...
  shouldTrace: true,
  additionalReporters: [{
    packageName: '@parcel/reporter-tracer',
    resolveFrom: __dirname,
  }],
});

格式

追踪 JSON 文件使用 Chrome 追踪格式，类似于 CPU 配置文件，但分析方式略有不同。

Parcel 追踪仅包含类型为 X 的完整事件。原始事件如下所示

{"ts":6020131,"pid":11738,"tid":4,"ph":"X","name":"@parcel/transformer-js","cat":"transform","args":{"name":"src/index.html"},"dur":11642},

分析追踪

虽然您可以将 Parcel 追踪加载到 Chrome Dev Tools 中，但该工具中针对此类配置文件的分析选项非常有限。这是因为数据不是 Dev Tools 设计用于处理的典型数据。例如，追踪事件包含可用于更深入分析的元数据，而这些元数据无法通过 Dev Tools 访问。此外，中型到大型的构建可能会生成大量数据，由于其大小，无法加载到 Chrome Dev Tools 中。

分析 Parcel 追踪的推荐工具是 Perfetto，它也是由 Google 构建的，但专门设计用于处理大型追踪和非浏览器追踪。特别是，Perfetto 中最适合分析这些追踪的部分是它将数据加载到一个 SQLite 数据库中，可以通过 UI 查询 - 这使我们能够回答前面提到的问题。

示例查询

以下是一些您可以输入 Perfetto 中“查询（SQL）”功能的示例查询，以生成有关 Parcel 构建的一些有用统计信息。请记住，这些结果中的持续时间是总采样时间 - 鉴于 Parcel 的多线程实现，其中一些总时间可能超过 Parcel 构建的实际时间。

我的构建按阶段的细分是什么？

这是一个高级查询，它按构建的主要阶段（构建、打包、封装）进行细分，可以帮助您在高级别上识别任何特定阶段是否比预期花费的时间更长。

select
  name, SUM(CAST(dur AS double)/1000/1000) as dur_ms
from
  slice s
where
  s.category = "Core"
group by name
order by dur_ms desc

我的构建中哪些插件花费的时间最长？

这对于在高级别上识别 Parcel 在哪些插件中花费的时间最长很有用。虽然其中一些将是核心插件，但在使用自定义插件或其他第三方插件的构建中，这可能是一个有用的查询，用于识别这些插件中是否有任何插件花费了意外的时间 - 这对于识别优化机会很有用。

select
  s.category, name, SUM(CAST(dur AS double)/1000/1000) as dur_ms
from
  slice s
left join
  args using(arg_set_id)
where
  args.flat_key = "args.name"
group by s.category, name
order by dur_ms desc

哪些 Babel 插件在我的构建中花费的时间最长？

这对于识别哪些 Babel 插件仍然需要在您的构建中使用，并由 @parcel/transform-babel 执行，这些插件花费的时间最长，因此可以优先考虑将其删除或替换为 Parcel 转换。

select
  name, SUM(CAST(dur AS double)/1000/1000) as dur_ms
from
  slice s
left join
  args using(arg_set_id)
where
  args.flat_key = "args.name" AND
  s.category LIKE "transform:@parcel/transformer-babel%"
group by name
order by dur_ms desc