效能陷阱：通用庫和輔助對象

Convenience and performance are typically inversely correlated. If the code is easy to use, it's less optimized. If it's optimized, it's less convenient. Efficient code needs to get closer to the nitty gritty details of what is actually running, how.

I came across an example in our ongoing work to run & optimize DeepCell cellular segmentation for cancer research. The DeepCell AI model predicts which pixels are most likely to be in a cell. From there, we "flood fill" from the most likely pixels, until reaching the cell border (below some threshold).

Part of this process involves smoothing over small gaps inside predicted cells, which can happen for various reasons but isn't biologically possible. (Think donut holes, not a cell's porous membrane.)

The hole-filling algorithm goes like this:

• Identify objects (contiguous pixels with a given cell label with the same numeric id).
• Compute the "Euler number" of these cells, a measure of the shape's surface.
• If the Euler Number is less than 1 (aka the surface has gaps), smooth out the holes.

Here is an example of Euler numbers from the Wikipedia article; a circle (just the line part) has an Euler characteristic of zero whereas a disk (the "filled-in" circle) has value 1.

We're not here to talk about defining or computing Euler numbers though. We'll talk about how the library's easy path to computing Euler numbers is quite inefficient.

First things first. We noticed the problem by looking at this profile using Speedscope:

It shows ~32ms (~15%) spent in regionprops. This view is left-heavy, if we go to timeline view and zoom in, we get this:

(Note that we do this twice, hence ~16ms here and ~16ms elsewhere, not shown.)

This is immediately suspect: the "interesting" part of finding the objects with find_objects is that first sliver, 0.5ms. It returns a list of tuples, not a generator, so when it's done it's done. So what's up with all the other stuff? We're constructing RegionProperties objects. Let's zoom in on one of them.

The tiny slivers (which we won't zoom into) are custom __setattr__ calls: the RegionProperties objects support aliasing, for instance if you set the attribute ConvexArea it redirects to a standard attribute area_convex. Even though we're not making use of that we still go through the attribute converter.

Furthermore: we aren't even using most of the properties calculated in the region properties. We only care about the Euler number:

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



<p>in turn, that only uses the most basic aspect of the region properties: the image regions detected by find_objects (slices of the original image).</p>

<p>So, we changed the code to fill_holes code to simply bypass the regionprops general-purpose function. Instead, we call find_objects and pass the resulting image sub-regions to the euler_number function (not the method on a RegionProperties object).</p>

<p>Here's the pull request: deepcell-imaging#358 Skip regionprops construction</p>

<p>By skipping the intermediate object, we got a decent performance improvement for the fill_holes operation:</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>For the larger image, 4s is ~3% of the overall runtime– not the bulk of it, but not too shabby either.</p>


          

            
  

            
        

以上是效能陷阱：通用庫和輔助對象的詳細內容。更多資訊請關注PHP中文網其他相關文章！