性能陷阱：通用库和辅助对象

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

我在我们正在进行的为癌症研究运行和优化 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 



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

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

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

<p>通过跳过中间对象，我们的 fill_holes 操作获得了不错的性能提升：</p>

<div class="table-wrapper-paragraph"><table>
<thead>
<tr>
<th>Image size</th>
<th>Before</th>
<th>After</th>
<th>Speedup</th>
</tr>
</thead>
<tbody>
<tr>
<td>260k pixels</td>
<td>48ms</td>
<td>40ms</td>
<td>8ms (17%)</td>
</tr>
<tr>
<td>140M pixels</td>
<td>15.6s</td>
<td>11.7s</td>
<td>3.9s (25%)</td>
</tr>
</tbody>
</table></div>

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


          

            
  

            
        

以上是性能陷阱：通用库和辅助对象的详细内容。更多信息请关注PHP中文网其他相关文章！