2. MERLIC运行时架构与性能瓶颈分析

MERLIC 的运行时并不是“加载图像 → 依次执行工具 → 输出结果”这样一条简单直线。它由执行引擎、工具链调度器、图像采集接口和结果输出通道共同组成，任何一环的阻塞都会以“整体节拍变慢”的形式暴露出来。理解这套架构，是后续做性能优化的前提：只有先判断瓶颈落在采集、调度、算子还是输出，优化才不会变成盲目调参。

执行引擎：MERLIC 的“心脏”

MERLIC 执行引擎负责加载已配置好的 VisionApp、解析工具链依赖、分配图像缓冲区并驱动整个处理循环。它内部维护一个处理循环（Processing Loop），每次循环大致经历四个阶段：等待新图像、执行工具链、生成结果、发布结果。引擎本身不直接做图像运算，而是把具体计算委托给底层 HALCON 算子，因此引擎层面的开销主要体现在缓冲区管理、工具间数据传递和结果序列化上。

一个容易被忽视的事实是：MERLIC 的工具链是按依赖顺序串行执行的。即使两个工具之间没有数据依赖，默认也不会并行。这意味着工具链的总耗时近似等于各工具耗时之和，再加上工具间的数据搬运开销。当工具数量较多时，数据搬运本身可能占到总耗时的 10%～20%。

工具链调度机制

MERLIC 的工具链调度遵循“数据就绪即触发”的原则。每个工具声明自己的输入端口和输出端口，调度器在每轮循环中检查哪些工具的输入已全部就绪，然后按拓扑顺序依次执行。这里有两个关键点：

• 工具粒度：一个工具内部可能包含多个 HALCON 算子，调度器只把工具当作一个整体，不会拆分到算子级别并行。
• 结果缓存：如果某个工具的输入在本轮没有变化，MERLIC 可能跳过重复计算，但这一优化依赖于工具是否被标记为“可缓存”。

因此，工具链的划分方式直接影响调度效率。把多个小算子合并成一个工具，可以减少调度开销；但合并过多又会导致单个工具内部无法被优化。实际工程中，通常建议把“采集 → 预处理 → 定位 → 测量 → 判定”作为五个独立工具，既保留可观测性，又避免过度碎片化。

图像采集与处理流水线

MERLIC 的图像采集通过 Image Source 接口完成，支持 GigE Vision、USB3 Vision、Camera Link 等标准。采集与处理之间通过一个环形缓冲区解耦：采集线程持续把新图像写入缓冲区，处理线程从缓冲区取最旧的一帧。这种设计允许采集和处理以不同速率运行，但缓冲区深度有限，一旦处理速度跟不上采集速度，缓冲区就会溢出，表现为丢帧或处理延迟累积。

下面这张图展示了 MERLIC 运行时从相机到结果输出的完整数据流，以及四个最典型的瓶颈位置。图中标注了每个环节的典型耗时量级（示例值，用于说明相对关系，非实测数据），便于对照排查。

常见性能瓶颈识别方法

识别瓶颈不能靠猜，需要把“总耗时”拆解到各环节。MERLIC 提供了几种可用的观测手段：

• 工具耗时统计：在 MERLIC Creator 的 Execution 面板中，每个工具会显示最近若干次执行的平均耗时。这是最直接的定位手段，能快速看出哪个工具最重。
• 帧率与丢帧计数：通过 Image Source 的状态信息查看实际采集帧率与丢帧数。如果采集帧率正常但处理帧率偏低，瓶颈在缓冲区之后。
• 循环周期测量：在结果输出端打时间戳，计算相邻两次输出的时间差。若该差值远大于工具耗时之和，说明存在等待或阻塞。

一个实用的排查顺序是：先看采集帧率是否达标，再看缓冲区是否溢出，然后看工具链中哪个工具耗时最高，最后看输出端是否有额外等待。这个顺序对应数据流的自然方向，能避免在错误环节反复调整。

一个可复用的瓶颈排查清单

下面这份清单可以直接用于现场排查，字段和判断依据都来自 MERLIC 运行时架构本身：

需要强调的是，MERLIC 的性能瓶颈往往不是单一环节造成的。采集端曝光偏长会导致帧率下降，处理端工具链偏重会导致缓冲区溢出，输出端通信阻塞又会反过来拖慢整个循环。实际优化时，应先用上述清单定位到主要矛盾，再针对该环节做参数调整或结构重组，而不是同时改动多个参数导致无法判断效果。