이러한 data augmentation 작업에 대해서 single core 에서 이만큼 걸리는건지, multi core 을 쓰고 있는건지, 각 해상도와 augmentation 정도마다 변환시간이 얼마나 달라지는지는 아직 모른다. TFRecord 생성 과정 중 어떤 부분에 병목이 있는지 분석하고, custom op 을 적용하는 방법이 효과적이라고 알려진 바 있지만 (참고3:대학생 대화챗봇 '이루다'를 만든 스캐터랩 핑퐁 블로그) 레퍼런스가 적고 엔지니어 리소스가 모자라기 때문에 이것을 마냥 잡고 있을 수 없다. 병목점을 분석하고 커널을 만들 여유가 없는 것도 사실이지만 TFRecord 생성에서의 우리의 병목은 augmentation 이다. Augmentation 커널을 C++ 로 구성하는 것은 유연성을 매우 잃어버린다. 무엇보다 지금(@11/8/2021, 6:32:00 PM) 할 작업은 아니다.
1개의 TFRecord 가 아니라 여러 분할로 나누어 생성하도록 (참고1:TFRecord를 가변적으로 조절해서 저장) 하거나, multi-core 을 쓰거나, 런타임 augmentatioin (참고2:TPU를 고려한 증강 파이프라인 구축 방법들) 을 이용해서 COLAB 의 단점을 극복하는 것도 방법이 될 수 있다.
참고