便利性和性能通常成反比。如果代码很容易使用，那么它的优化程度就较低。如果优化的话就不太方便了。高效的代码需要更接近实际运行的内容、运行方式的细节。

我在我们正在进行的为癌症研究运行和优化 DeepCell 细胞分割的工作中遇到了一个例子。 DeepCell AI 模型可以预测哪些像素最有可能位于细胞中。从那里，我们从最可能的像素“洪水填充”，直到到达单元格边界（低于某个阈值）。

这个过程的一部分涉及平滑预测细胞内的小间隙，这可能由于多种原因而发生，但在生物学上是不可能的。 （想想甜甜圈孔，而不是细胞的多孔膜。）

补洞算法是这样的：

• 识别对象（具有相同数字 id 的给定单元格标签的连续像素）。
• 计算这些单元的“欧拉数”，即形状表面的度量。
• 如果欧拉数小于 1（即表面有间隙），请平滑孔洞。

这是维基百科文章中欧拉数的示例；圆（仅直线部分）的欧拉特征为零，而圆盘（“填充”圆）的值为 1。

不过，我们不是在这里讨论定义或计算欧拉数。我们将讨论该库计算欧拉数的简单路径为何效率很低。

首先要做的事情。我们通过使用 Speedscope 查看此配置文件注意到了这个问题：

它显示在 Regionprops 上花费了约 32 毫秒（约 15%）。这个视图是左重的，如果我们进入时间轴视图并放大，我们会得到这个：

（请注意，我们执行了两次，因此此处约为 16 毫秒，其他地方约为 16 毫秒，未显示。）

这立即令人怀疑：使用 find_objects 查找对象的“有趣”部分是第一个条子，0.5 毫秒。它返回一个元组列表，而不是生成器，所以当它完成时就完成了。那么其他的东西又怎么样呢？我们正在构造 RegionProperties 对象。让我们放大其中之一。

这些小条子（我们不会放大）是自定义 __setattr__ 调用：RegionProperties 对象支持别名，例如，如果您设置属性 ConvexArea，它会重定向到标准属性 area_convex。即使我们没有使用它，我们仍然会使用属性转换器。

此外：我们甚至没有使用区域属性中计算的大部分属性。我们只关心欧拉数：

props = regionprops(np.squeeze(label_img.astype('int')), cache=False)
for prop in props:
    if prop.euler_number 



反过来，它仅使用区域属性的最基本方面：find_objects 检测到的图像区域（原始图像的切片）。

因此，我们将代码更改为 fill_holes 代码，以简单地绕过regionprops通用函数。相反，我们调用 find_objects 并将生成的图像子区域传递给 euler_number 函数（而不是 RegionProperties 对象上的方法）。

这是拉取请求：deepcell-imaging#358 跳过 Regionprops 构建

通过跳过中间对象，我们的 fill_holes 操作得到了不错的性能提升：




图像尺寸
前
后
加速




26万像素
48ms
40ms
8 毫秒 (17%)


1.4亿像素
15.6s
11.7秒
3.9秒（25%）




对于较大的图像，4s 约占整体运行时间的 3%——不是大部分，但也不算太差。