영상처리 프로세스 소요시간이 10초에 가까운 문제가 있었다.
이 문제를 해결하기 위한 시도했던 경험을 풀어보고자 한다.

멀티스레드을 활용한 고속 처리

소요시간 약 9.8초 -> 3.5초

먼저 이러한 당황스러운 소요시간은 필터 사이즈가 워낙에 컸던 탓에 처리시간이 늘어지는 문제였다.

최우선으로 시도했고 가장 큰 성능향상을 이끌어냈다.
자세한 내용은 멀티스레딩을 활용한 고해상도 이미지의 고속 처리 에서 볼 수 있다.

소요시간이 정직하게 1/8 로 줄어들지 않은 것은 전체 프로세스에서 영상 처리에 차지하는 비중에 따른 결과이다.

Release 모드 사용

약 3.5초 -> 2.2초

문득 당연한것 같으면서도 이런게 있는줄 모른다거나, 알아도 신경쓰지 않는다면 Debug 모드로 빌드된 파일을 배포하는 경우도 있을 수 있다.
실제로 주변에서 이 모드를 모르는 경우도 보았고, 알아도 신경쓰지 않는 경우 또한 보았다.

개발환경에 기본적으로 설정되어 있는 Debug 모드는 디버깅에 필요한 추가적인 작업이 들어가므로 파일 사이즈가 커지는것 뿐 아니라 실행속도까지 느려지게 된다.
반면 Release 모드는 컴파일러에서 추가적인 코드 최적화가 이뤄지고 이로 인한 속도 향상도 유의미하게 기대할 수 있다.

꽤 드문 일이지만 간혹 컴파일러의 코드 최적화 단계에서 과도한 최적화로 코드의 동작이 기대와 다른 치명적인 문제가 발생할 수 있다. IDE의 설정에서 이러한 unsafe 와 관련된 설정을 on/off 할수도 있고 C++ 언어 표준에서 이를 막기 위한 별도의 기능을 제공하기도 한다.

멀티스레드로 이미지 저장 기능 분리

소요시간 약 2.2초 -> 1.1초

전체 소요시간을 분석하던 중 결과 이미지 파일을 가공한뒤 저장하는 i/o 작업에 무려 절반의 시간이 소요된다는 문제점을 발견했다.
이에 i/o 전용 스레드를 추가하여 처리 결과에 따른 이미지를 별도 스레드에서 처리하도록 하여 i/o 작업에 의한 병목 문제를 해결했다.
이로 인해 작업 스레드는 순수한 처리 프로세스에만 집중하고 결과물인 이미지는 신경쓰지 않고 바로 다음 검사 프로세스의 준비에 임하게 되었다.

과도한 분량의 결과 데이터 제한

간헐적으로 증가하던 소요시간의 안정화

이미지의 처리 과정 중 간헐적으로 과도하게 많은 불량을 갖고 있는 경우 이를 처리하기 위한 소요시간이 늘어지는 문제가 발견되었다.
이러한 불량 정보는 존재여부가 1순위로 중요했고 그 정보의 구체적인 데이터는 일정치를 넘으면 불필요했기 때문에 불량 정보에 대한 처리량을 제한하여 처리속도를 일관되게 유지하게 만들었다.

64비트 환경 설정

소요시간 1.1초 -> 0.9초

이 내용은 순수한 호기심으로 테스트해보았다.
개발 장비와 실제 운영 장비 모두 64비트 환경인데 프로젝트 빌드를 32비트를 할 필요가 없다는 판단이었다.
그리고 별 차이 없을것 같다는 예상을 넘어, 유의미한 수준의 성능 향상이 있었다.

다만 이러한 설정 변경은 사용하는 환경에 따라 적용(빌드)이 불가능할 수 있다.

마치며

보시다시피 사실 이 과정은 단순히 두 부분의 멀티스레딩 활용과 두 종류의 환경설정 변경 그리고 약간의 편법으로 이뤄진 결과이다. 어찌보면 당연하다 싶은 수준의 내용일 수도 있으나,

자칫하면 놓칠 수도 있는 사소해 보이는 개선점도 누적되다보면 유의미한 수준의 성능개선을 이뤄낼 수도 있고 반대로 사소한 최적화도 무신경하게 방치한다면 큰 성능낭비가 될 수 있다는 사실을 체감하게 된 경험이었다.