[Instruments 맛보기] 훌륭한 프로파일링 경험

🏁 학습할 내용

• os_signpost(Tracing)
• struct to temporal data (Modeling)

---

🚥 os_signpost

 

⭐️  역할

저비용 추적에 사용되는 로깅 시스템

 

🔷 형태

• swift는 begin, end, event라는 3가지 유형의 API를 제공
• logHanlde은 사실상 nameSpace, subsystem과 category를 지정할 수 있음
• static 이름과 함께 추적 지점의 논리적 구조와 계층 구조가 제공

 

👍 장점

 

동시성 환경에서도, 높은 수준으로 지원한다.

• 시작 또는 종료 이벤트가 서로 다른 스레드여도, signpostID를 통해 이벤트를 일치시킬 수 있다.

 

높은 정확도의 타임스탬프가 기록된다.

 

 

비용이 저렴하다.

• 최소한의 데이터만 저장
  • 정적 문자열 + 메타 데이터는 이진 텍스트 세그먼트에 오프셋으로 출력됨
• 그렇기때문에, #DEBUG같은 걸로 분기를 따로 할필요가 없다. 

 

많은 정보를 제공한다.

• 암묵적 정보
  • 시간
  • 스레드
  • 프로세스
  • 스코프
  • backtrace
• 명시적 정보
  • event 타입
  • subsystem
  • category
  • name
  • id
  • format-string
  • message

 

✈️  모드

 

sdefault

•  링 버퍼에 기록
• 저렴한 비용

streaming

• 실시간으로 instruments에 표시되는 모드
• 높은 비용

dynmaic

• 녹을 될때만 활성화
• default보다 더 많은 정보를 얻는 대신, 오버헤드가 조금 더 있음, 하지만 여전히 저렴한 비용
• dynamicTracing: 동적인 추적
• dynamicStackTracing: dynamicTracing + 호출 스택

    let defaultLog = OSLog.default
    let dynamicTracingLog = OSLog(subsystem: "com.org.MyFramework", category: .dynamicTracing)
    let dynamicStackTracingLog = OSLog(subsystem: "com.org.MyFramework", category: .dynamicStackTracing)

 

🤔 어떻게 효율적으로 사용할 수 있을까?

 

지연 모드를 사용하자.

• 스트리밍 모드(실시간 추적)은 항상 다른 모드 보다 높은 비용이 든다.
• 템플릿을 열 때 설정할 ㅅ. 잇음

dynamic 모드를 사용하자.

• 기본적으로 signpost가 꺼져 있기 때문에, 오버헤드를 최소화
• 필요할 때, custom instruments에서만 활성화 가능
• 내장된 OSSignpost의 트랙을 혼잡하게 만들지 않음 (노이즈 최소화)

 

생각보다 많은 개수를 넣어도 ㄱㅊ

• 싱글 코어에서, 프로파일링에 사용하는 CPU 사용량을 1% 미만을 목표로 잡아보자.
• 만약, 활성화된 signpost 약 0.5 마이크로 초라고 가정
• 1초당 2만개의 signpost, 120프레임 기준, 약 83개 간격으로 표시할 정도로 여유

 

그렇다고 무분별한 사용은 하지말자

• signpost는 시스템의 공유 자원이다.
• 많이 사용할수록, 로깅시스템에 영향력이 커짐
• 따라서, 여러 category로 구분하여, 필요한 부분만 빠르게 확인할 수 있도록 하자.

 

👍 모범 사례

 

시작한 간격은 반드시 끝내라

• 시작한 Interval을 끝내지 않으면, 분석 속도가 크게 느려지고, 정확성이 매우 떨어짐
• 좋은 방법은 defer 구분을 이용하면, 별도 코드 흐름을 크게 신경쓰지 않아도 된다.

추적 시작과 종료 지점에서 동일한 데이터를 기록을 피해라

• 가능한 시작 지점에서 기록
• 구분 값을 사용하고 싶으면, 차라리 Signpost ID를 생성해서 활용하자.
• 중복 작업이 방지된 만큼, Instruments에서 가능한 빨리 값을 제공 받을 수 있음

signpost는 활성화되지 않은 상태에서 불필요한 작업을 피해라

• signpostEnabled 플래그 속성을 활용해, 해당 시점에 기록중인 지 판단
• 활성화 여부를 확인한 뒤, 작업을 진행하는 것이 효율적

Instruments에 필요한 데이터만 추적해라

---

📊 modeling and adding structure to data within Instruments

 

🏗️ Instruments Architecture

 

Instruments의 모든 내용은 테이블에 저장된 내용을 기반으로 동작한다.

schema는 테이블의 구조를 정의하며, 모든 테이블은 Instruments Instant Analysis Core을 통해 측정됨

 

이제 각 과정을 살펴보자.

 

Tracing

• 앞에서 배운 Tracing은 데이터 소스를 기록하는 과정

 

Modeling

• 모델링은 중간 단계이며, 모델러는 하나 이상의 입력 테이블에서 데이터를 관찰한 후, 이유를 추론한다.
• 이후 사용자가 지정한 하나 이상의 출력 테이블에 데이터를 출력한다.
• 모델러는 도메인별 로직이 있는 곳이며, 출력 테이블의 스키마는 데이터에 적용할 유형과 포맷터를 지정하는 데 사용된다.

 

Visualization

 

 

• 마지막 단계는 모델러의 출력 테이블 데이터를 그래프로 표시하고, 표시 방법을 지정하는 단계
• 예를 들어, 어떤 열을 그릴 지, 어떤 값을 사용할지, 어떤 색상 레이블로 표시할 지를 지정할 수 있다.

---

⚠️ 커스텀 Instruments 만들 떄 주의할 점

 

OSSignpost확인과 스키마 매핑

• 커스텀 Instruments의 Visualization은 스키마와 모델러의 출력을 기반으로 한다
• 그렇기 떄문에, OSSignpost 추적 상태가 양호한지, 데이터를 사용자 스킴으로 정의하는 과정을 확인하는 것은 매우 중요!

 

데이터 저장 방식

• 커스텀 Instruments는 반드시, 두가 지 방식 중 하나를 채택해야함
  • Point Schema: timestamp 열만 필요 (단일 시점 이벤트)
  • Interval Schema: timesatmp와 duration 열이 필요 (기간이 있는 이벤트)
• 최소 하나 이상의 Point 또는 Interval schema를 정의하고, 나머지 열들은 이름과 데이터 타입을 직접 제공

 

모데링 규칙 정하기

• 규칙은 Eclipse 언어로 표현된다.
• 다행히 Instruments는 모델러를 자동 생성하는 몇가지 shcema를 제공
• 따라서, 직접 Eclipse 코드까지 짤 경우는 많이 없다.

 

실제 데이터가 정확한지 확인하기

• Instruments 라이브러리에 내장된 OSSignpost 도구를 사용하면, 간격과 데이터 예상값의 정확도를 살펴볼 수 있다.

---

출처

https://developer.apple.com/videos/play/wwdc2019/414/