성능 함정: 일반 라이브러리 및 도우미 개체

편의성과 성능은 일반적으로 반비례 관계에 있습니다. 코드가 사용하기 쉽다면 덜 최적화됩니다. 최적화되면 덜 편리합니다. 효율적인 코드는 실제로 실행되는 내용과 방법에 대한 핵심적인 세부 사항에 더 가까워야 합니다.

저는 암 연구를 위해 DeepCell 세포 분할을 실행 및 최적화하기 위해 진행 중인 작업에서 한 가지 예를 발견했습니다. DeepCell AI 모델은 셀에 어떤 픽셀이 있을 가능성이 가장 높은지 예측합니다. 거기에서 가장 가능성이 높은 픽셀부터 셀 경계(일부 임계값 아래)에 도달할 때까지 "플러딩 채우기"를 수행합니다.

이 프로세스의 일부에는 예측된 세포 내부의 작은 간격을 평활화하는 작업이 포함되는데, 이는 다양한 이유로 발생할 수 있지만 생물학적으로는 불가능합니다. (세포의 다공성 막이 아닌 도넛 구멍을 생각해보세요.)

구멍 채우기 알고리즘은 다음과 같습니다.

• 객체를 식별합니다(동일한 숫자 ID를 가진 주어진 셀 레이블이 있는 연속 픽셀).
• 모양의 표면을 측정하는 이 셀의 "오일러 수"를 계산합니다.
• 오일러 수가 1보다 작은 경우(즉, 표면에 틈이 있는 경우) 구멍을 매끄럽게 만듭니다.

다음은 Wikipedia 기사에 있는 오일러 수의 예입니다. 원(선 부분만)의 오일러 특성은 0인 반면 디스크("채워진" 원)의 값은 1입니다.

하지만 우리는 오일러 수를 정의하거나 계산하는 것에 대해 이야기하기 위해 여기 있는 것이 아닙니다. 오일러 수를 계산하는 라이브러리의 쉬운 경로가 얼마나 비효율적인지 이야기하겠습니다.

가장 중요한 것부터. Speedscope를 사용하여 이 프로필을 보고 문제를 발견했습니다.

regionprops에서 ~32ms(~15%)가 소비된 것으로 표시됩니다. 이 보기는 왼쪽이 많습니다. 타임라인 보기로 이동하여 확대하면 다음과 같은 결과를 얻습니다.

(이 작업을 두 번 수행하므로 여기서는 ~16ms이고 다른 곳에서는 ~16ms이며 표시되지 않습니다.)

이것은 즉시 의심됩니다. find_objects를 사용하여 개체를 찾을 때 "흥미로운" 부분은 첫 번째 부분인 0.5ms입니다. 생성기가 아닌 튜플 목록을 반환하므로 완료되면 완료된 것입니다. 그럼 다른 것들은 모두 어떻게 되나요? 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>그래서 우리는 단순히 Regionprops 범용 함수를 우회하기 위해 코드를 fill_holes 코드로 변경했습니다. 대신 find_objects를 호출하고 결과 이미지 하위 영역을 euler_number 함수(RegionProperties 개체의 메서드 아님)에 전달합니다.</p>

<p>풀 요청은 다음과 같습니다: deepcell-imaging#358 지역 속성 생성 건너뛰기</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 중국어 웹사이트의 기타 관련 기사를 참조하세요!