这一流程中，需要注意一些细节：
1、递归搜参：MegDNN 中普遍存在算子嵌套的情况。例如，Convolution 算子中，Im2col 算法会使用 MegDNN 的 MatMul 算子执行矩阵乘计算。那么，Convolution 的性能直接受到 MatMul 性能的影响。可以看到，在 Profiling 一个 Convolution 算子之前，需要 MatMul 算子执行的性能数据已知。为了解决这个问题，Fast Run 使用了递归的方式，来解决搜参时的算子嵌套问题。如上图中虚线框所示，一个 MegDNN 算子，在获取所有可用算法之后，会调用每个算法的接口，询问该算法是否依赖子算子并保存相关结果，若最终相关结果不为空，则会先对子算子进行一次 Profiling，此后，再 Profiling 顶层的算子时，其使用的子算子会有最优的算法保存在 Cache 中。
2、Fast Run 性能数据保存：Fast Run 性能数据存取离不开 Cache。MegEngine 提供了两种 PersistentCache，两种 Cache 区别于数据保存的位置（内存或是文件）。Cache 的结构如下图所示：
MegEngine 中，PersistentCache 对象是单例的，两种 Cache 都保证线程安全。Cache 维护一个从 category 信息到一个集合的映射的集合，此处 category 是一个后端的记录信息。Category 是一个字符串，由后端信息和算子类型拼接获得，后端信息 由设备区分，例如 CUDA 的后端信息由设备名称、NVIDIA 驱动版本和 CUDA 运行时库版本信息组成；CPU 作为后端时，则只记录设备名称。MegEngine 中只有 CUDA、CPU、ROCM 三种类型有对应的 categoty 生成，这也是 MegEngine 目前仅支持在 CUDA、CPU、ROCM 三个后端支持 Fast Run 的原因。算子类型 由算子名称、Cache 版本信息两部分组成。
一个 category 映射到一个集合，该集合维护单个 MegDNN 算子的信息到其所有可用算法的 Profiling 结果的映射。该集合的 key值 由 MegDNN 算子的所有输入 Tensor 的尺寸和算子的全部参数组成（这些参数能够完全决定一个算法是否可用）。value值 是一个数组，保存每个 Profiling 过的算法的时间、所需额外的空间等信息，并排序。排序时，以运行时间进行升序排列，并且保证了序列中每个算法使用的内存必须小于其前一个算法使用的内存 – 这样序列中不存在一个算法既慢于另一个算法，又使用更多的内存。一个 Cache 中可以存在不同后端的 Fast Run 结果，只要它们的 category 不同。
在一些常见的模型上，推理时关闭和开启 Fast Run，性能表现如下：
从工程落地中 Fast Run 的使用情况来看，绝大部分场景下，能显著降低网络运行时间。
四、Fast Run 使用MegEngine 可配置的参数众多，很多都是工程落地的解决方法，在工业上经过大量的实践。其中一些参数与 Fast Run 的使用有密切的关系，这里详细阐述它们的使用。
4.1 开启 Fast Run源代码级别使用 Fast Run 可以参照 MegEngine 自带的可执行程序 load_and_run，如果仅关注利用 load_and_run 测试模型，有下面两个参数需要使用：
--full-run/--fast-run，搜参的两种模式，需用户选择其中一种模式，两者的区别在于 Profiling 时，生成的 MegDNN 算子的可用算法集大小不同。--full-run 时，会 Profiling MegDNN 算子内所有的可用算法，包括最朴素的算法（MegDNN 算子至少有一个算法，保证任何参数下均可用，运行慢）。--fast-run 则会排除朴素算法。如果想要减少 Profiling 的时间开销，可以选择使用 --fast-run 模式，此时需要注意的是，如果网络中有参数过于特殊的算子，则该算子可能面临没有可用算法的情况（优化过的算法不可用、朴素的算法被排除），此时 MegEngine 会报出“没有可用算法”的错误并退出。