便利性和性能通常成反比。如果代码很容易使用，那么它的优化程度就较低。如果优化的话就不太方便了。高效的代码需要更接近实际运行的内容、运行方式的细节。
我在我们正在进行的为癌症研究运行和优化 DeepCell 细胞分割的工作中遇到了一个例子。 DeepCell AI 模型可以预测哪些像素最有可能位于细胞中。从那里，我们从最可能的像素“洪水填充”，直到到达单元格边界（低于某个阈值）。
这个过程的一部分涉及平滑预测细胞内的小间隙，这种情况可能因多种原因而发生，但在生物学上是不可能的。 （想想甜甜圈的孔，而不是细胞的多孔膜。）
空洞填充算法如下：
这是维基百科文章中的欧拉数示例；圆（仅直线部分）的欧拉特征为零，而圆盘（“填充”圆）的值为 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 < 1:
反过来，它仅使用区域属性的最基本方面：find_objects 检测到的图像区域（原始图像的切片）。
因此，我们将代码更改为 fill_holes 代码，以简单地绕过 Regionprops 通用函数。相反，我们调用 find_objects 并将生成的图像子区域传递给 euler_number 函数（而不是 RegionProperties 对象上的方法）。
这是拉取请求：deepcell-imaging#358 跳过 Regionprops 构建
通过跳过中间对象，我们的 fill_holes 操作获得了不错的性能提升：
| Image size | Before | After | Speedup |
|---|---|---|---|
| 260k pixels | 48ms | 40ms | 8ms (17%) |
| 140M pixels | 15.6s | 11.7s | 3.9s (25%) |
对于较大的图像，4s 约占整体运行时间的 3%——不是大部分，但也不算太差。
以上是性能陷阱：通用库和辅助对象的详细内容。更多信息请关注PHP中文网其他相关文章！
