性能分析和追踪

追踪

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},

分析追踪

虽然您可以在 Chrome 开发工具中加载 Parcel 追踪，但该工具对这类性能分析的分析选项相当有限。这是因为数据不是开发工具设计用于处理的典型数据。例如，追踪事件包含可用于更深入分析的元数据，但这些元数据在开发工具中是不可访问的。此外，中等到大型的构建可能会产生大量数据，以至于无法在 Chrome 开发工具中加载。

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

示例查询

以下是您可以在 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 插件花费的时间最长？

这可用于识别在构建中仍然需要的、由 @parcel/transform-babel 执行的 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