Swift) 2016 WWDC Understanding Swift Performance를 공부하며,

안녕하세요, 보노입니다!

WWDC 2016 Understanding Swift Performance

본 포스팅은 과거 위 세션을 내 코드 어디에 적용시킬 수 있는 지가 와닿지 않아 헤매다, 당시 나름대로 내린 답을 짧게 정리한 포스팅입니다.

누군가에겐 당연한 내용이기에 포스팅을 망설였으나,

24년도의 목표를 '부족함을 직면하고 자주 실패한다'로 설정하였기 때문에 자신없는 주제 또한 남겨두는 것이 좋겠다 생각이 들었습니다.

일기에 가까운 글이며 부족하지만, 늘 그랬듯 누군가에게는 도움이 되는 글이길 바랍니다.

Allocation(할당)이 성능에 미치는 영향

우선, WWDC 2016 Understanding Swift Performance 에서는 Swift의 성능 기준을 아래와 같이 제시한다.

성능을 평가하는 기준은 총 세 가지이다.

(1) Allocation (할당)

• 인스턴스를 어디에 할당?
  => Stack / Heap

(2) Reference Counting (참조 카운팅)

• 인스턴스 전달 시 참조 카운팅은 얼마나 많이? (오버헤드는 얼마나 많이?)
  => Less / More

(3) Method Dispatch (메소드 디스패치)

• 인스턴스 메서드 호출 시 어떻게 동작?
  =>Static / Dynamic

좌측일수록 성능이 좋고, 우측일수록 성능이 나쁘다.

세 가지의 기준 중 할당에 대한 이야기를 이어가 보자.

Swift의 인스턴스는 힙 영역 또는 스택 영역에 할당된다.

Struct(값 타입)는 스택에 쌓이고 Class(참조 타입)은 Heap 영역에 저장된다.

그러니 나는 익숙히 Stack / Heap의 특성을 Struct / Class로 대리표현하기도 했다.
(예외 상황이 있기에 옳은 표현 방법은 아니다)

값싼 점토와 값비싼 점토, Struct와 Class

나는 개념을 비유하여 이해하기를 즐기기에,
Struct와 Class를 점토에 같이 비유하고자 한다.

Struct와 Class를 점토재료에 비유하자면, Struct는 딱딱한 대신 값이 싼 점토, Class는 유연하고 부드러운 대신 비싼 점토이다.

값비싼 점토인 Class는 그 유연성을 보장하기 위한 재료로 만들어져 구입하는 데 드는 값이 크고, 흐물거리는 모양을 유지하기 위해 들이는 노력 값도 크다.

( 하지만 경우에 따라 값싼 Struct가 Class 사용보다 더 큰 비용을 지불해야 하는 경우가 존재한다.
해당 WWDC에서는 Allocation 부분을 설명하며 해당 내용을 다룬다 )

그러니 문득 이러한 생각이 들었다.

'비용'을 낮추려면(성능 높임) 무조건 딱딱한 점토(Struct)를 써야 하는 게 아닌가?

성능? 무조건 좋아야 좋은 게 아닌가?

애초에 해당 영상을 알아서 무엇이 좋은 지 이해가 되지 않았다.

그러나 위 질문은 무조건 싼 코드가 좋은가? 로 바꾸어 적으면 이해에 도움이 되는 것 같다.

뭔들 무조건 싼 게 좋은 건 아니었는데...? 란 추측으로 이어지기 때문이다.

해당 세션에서는 언급되지 않지만 (당연해서 그런 걸지도 모르겠다... 하지만 난 몰라서 이해가 어려웠다) Swift 성능 최적화에는 당연히 전제된 상황이 존재해 보인다.

(이를 짚고 넘어가지 않으면 무조건 struct 쓰면 좋은 건가? 하고 생각하게 된다)

처음으로 돌아가서,

성능평가에 대한 기준을 알아야 하는 이유는 뭘까.

내 나름 합리적으로 추측한 바는 아래와 같다.

성능평가는 원하는 상황에 대한 상대평가이다. 원하는 상황이 인스턴스를 힙에 할당하고 참조하는 것이 적합하다면 struct로 변환하여 성능을 높이는 일이 필요치 않다는 것이다.

예를 들어보자.

이곳저곳에서 접근해도 유연하게 움직이는 인형을 만들고자 한다.

이는 비싼 기능이기 때문에 원재료값으로 비싼 값을 지불해야함이 당연하다. 그러나 싸다는 이유로 딱딱한 점토를 구입하여 만들고자 한 인형을 만들지 못하게 된다면?

애초에 기획 의도를 따르지 않았으니 결과물이 산으로 간 셈이다.

그러니 코드의 성능을 고려하고자 한다면,

1) 내 코드에서 위의 세 기준 중
2) 불필요한 값이 지불되고 있는 지 확인하고
3) 합의가 가능한 부분을 최대한 줄이면

코드의 성능을 높일 수 있을 것이다.

정리하자면,

내 코드가 얼마나 많은 비용을 사용하고 있는 지,
그게 타당한 지출인 지를 알고자 한다면 값을 치루는 기준, 위의 세 기준을 알 필요가 있다.

이러한 생각을 거치고 났더니 (다행히) WWDC 2016 Understanding Swift Performance 세션을 재미있게 볼 수 있었다.

필요한 동작을 충족하는 코드라면 싸면 쌀 수록 좋다 !

---

애초에 왜 해당 세션이 편성되었는가-- 에 대해 이해하기 위한 과정이었습니다.

벨로그에 팔로우 기능이 생겨서 신기합니다!

댓글은 늘 감사히 읽고 있으니 문제 되는 부분이 있다면 언제든 편히 알려주세요!

감사합니다! 아요쓰 화이팅 !