为何分支目标时钟时间远长于报告执行时间？假设是否合理？

我正在优化一个高度并行且内存密集型的targets管道，发现下游动态分支目标的挂钟时间（wall clock time）远长于该目标的报告执行时间。示例：

● built branch PSUT_Re_all_Chop_all_Ds_all_Gr_all_f29c72e5 [11.05 seconds]
实际挂钟时间为20.07秒。我希望尽可能缩小挂钟时间与执行时间的差异，想先明确导致这种差异的原因。

背景信息：

• 每个分支目标（如_f29c72e5）的输入数据由更大的上游数据框目标的行动态生成；
• 按照高性能并行管道的建议，设置了storage = "worker"和retrieval = "worker"；
• 针对高内存管道，设置了memory = "transient"和garbage_collection = TRUE；
• 在交互式会话中，使用tar_read()读取整个上游数据框需约8秒，几乎等于挂钟时间与执行时间的差值。

我的假设是：每个动态生成的下游分支都会加载整个上游目标，切片后再将切片发送至分支目标的函数。请问该假设是否合理？若合理，我将创建示例项目并进一步询问解决方案。

你的假设完全合理。

从背景数据来看，挂钟时间与执行时间的差值（约9秒）和tar_read()读取上游数据框的耗时（约8秒）高度吻合，这直接验证了你的猜想：每个动态分支在执行核心逻辑前，都需要先完整加载上游的大数据框目标，再从中切分出当前分支所需的子集。这个加载过程的时间并未被计入目标的报告执行时间，但会占据挂钟时间的一部分，最终导致两者出现显著差异。

结合你设置的storage = "worker"和retrieval = "worker"参数，上游目标的存储与获取都在worker节点完成，每个分支启动时都要独立读取完整的上游数据，进一步放大了这一时间损耗。

若要优化该问题，可考虑两种方向：一是提前对上游数据框进行预分片，让每个分支直接读取对应分片而非完整数据；二是调整targets的分支策略，将切片逻辑提前在主进程完成，避免worker重复加载完整数据。你可以创建示例项目后，再深入探讨具体的实现方案。

内容的提问来源于stack exchange，提问作者Matthew Kuperus Heun