Swift Dispatch 메커니즘과 Existential Container

다양한 타입을 섞어 저장하는 정당한 이유가 있는지 확인. 단일 타입이면 Generic으로 변경.

배열 순회 시 any를 사용하면 매번 Unboxing. 성능 병목이면 Generic 고려.

상속이 필요한 경우만 Class. 그 외에는 Struct로 Static Dispatch 활용.

상속하지 않는 Class는 final로 선언해서 Static Dispatch 가능하게.

추측하지 말고 Instruments로 실제 병목 지점 확인 후 최적화.

24 bytes 이하의 작은 Struct는 inline 저장. 큰 값은 힙 할당 고려.

답: any Protocol 타입의 값을 저장하는 특수한 메모리 구조입니다.

• 고정 크기: 40 bytes
• 구조: Value Buffer (24B) + VWT (8B) + PWT (8B)
• 택배 상자처럼 "다양한 크기의 값을 하나의 상자에 담는 방법"

Point는 16 bytes, Circle은 28 bytes인데 any Drawable 변수 하나로 둘 다 저장할 수 있는 이유가 바로 이 Container 덕분입니다.

답:
• VWT (Value Witness Table): "이 값을 어떻게 복사/삭제하나?" (값 관리)
• PWT (Protocol Witness Table): "draw()를 어떻게 호출하나?" (메서드 호출)

비유:
VWT = "취급 주의" 스티커
PWT = "사용 설명서" 스티커

답: 구체 타입 (Circle)을 Existential Container에 포장하는 과정입니다.

과정:
1. Container 할당 (40 bytes)
2. 값 복사 (Value Buffer에)
3. VWT 주소 저장
4. PWT 주소 저장

원래 스택에 8 bytes로 저장될 Circle이 40 bytes Container에 담기게 됩니다.

답: 2가지 경우에 발생합니다.

1. 메서드 호출:
drawable.draw()
→ PWT 조회 → Value Buffer에서 값 꺼내기 → 메서드 실행

2. 타입 캐스팅:
if let circle = drawable as? Circle
→ 런타임 타입 체킹 → 값 추출

모두 런타임에 발생합니다.

답: Boxing을 다르게 표현한 것입니다.

구체 타입: Circle, Point처럼 실제 타입 이름이 있는 것
변환: Circle (8 bytes) → Container (40 bytes)로 형태가 바뀜

마치 책상 위의 책 (Circle)을 택배 상자에 넣는 것과 같습니다.
타입도 Circle → any Drawable로 바뀝니다.

답: 둘 다 맞습니다.

• 컴파일 타임: 컴파일러가 "여기에 Boxing이 필요하다"고 판단하고 코드 삽입
• 런타임: 실제로 Container에 값을 복사하는 실행

컴파일러가 미리 알고 준비해두고, 실제 실행은 런타임에 발생합니다.

답: Boxing/Unboxing 오버헤드 때문입니다.

Generic:
• Boxing 없음
• 런타임 타입 체킹 없음
• Witness Table은 컴파일 타임에 결정

any:
• 매번 Boxing (40 bytes 할당 + 복사)
• Unboxing (PWT 조회 + 값 꺼내기)
• 큰 값은 힙 할당까지

하지만 "여러 타입을 섞어 저장"할 때는 any가 필수입니다.

답: Value Buffer에 직접 저장되기 때문입니다.

작은 값 (≤ 24 bytes):
Container의 Value Buffer에 inline 저장 (힙 할당 없음) ✅

큰 값 (> 24 bytes):
힙에 할당하고 포인터만 Value Buffer에 저장 (힙 할당 오버헤드) ❌

따라서 작은 Struct를 사용하는 게 성능에 유리합니다.

답: 기본적으로 스택에 저장됩니다.

일반 변수:
let drawable: any Drawable = ... → 스택 ✅

클래스 프로퍼티:
class ViewModel { var drawable: any Drawable } → 힙 (클래스가 힙에 있으므로)

escaping 클로저 캡처: → 힙

중요: Container 자체의 위치와, Value Buffer 안의 값이 힙에 있는지는 별개입니다!

답: Value Buffer에 **데이터를 직접** 저장하는 방식입니다. (≤ 24 bytes)

Inline 저장 (메모리 점프 없음):
• Container의 Value Buffer 안에 데이터를 직접 저장
• 연속된 메모리 주소에 값이 나란히 배치
• Container 읽을 때 **메모리 점프 없이** 바로 데이터 접근 ✅
• 예: [x: 10, y: 20] ← Value Buffer에 직접 저장

Non-Inline 저장 (메모리 점프 발생):
• Value Buffer에는 **힙 포인터만** 저장
• 실제 데이터는 힙의 다른 주소에 위치
• 데이터 읽으려면 **메모리 점프 발생** (Container → 힙) ❌
• 예: [heap pointer → 0x7ffeab3c] → 힙의 데이터

핵심: Inline = 연속된 메모리, Non-Inline = 포인터 따라가야 함 (캐시 미스 가능성)

답: CPU 캐시에 데이터가 없어서 느린 메인 메모리까지 가야 하기 때문입니다.

속도 차이:
• 캐시 히트 (데이터가 캐시에 있음): ~1-10 사이클 ✅
• 캐시 미스 (메인 메모리까지 가야 함): ~100-300 사이클 ❌

Inline 저장: 연속된 메모리 → 캐시에 한 번에 로드 → 캐시 히트
Non-Inline: 메모리 점프 (스택 → 힙) → 캐시 미스 가능성 높음

약 10-30배 속도 차이!

답: Array는 특수한 경우입니다.

Array 구조:
• buffer pointer (힙 가리킴) + count + capacity
• 약 24 bytes (메타데이터만)

결과:
• Array 구조체는 Value Buffer에 inline 저장 가능
• 하지만 실제 배열 요소는 항상 힙에 저장됨
• 결국 포인터를 따라가야 하므로 Non-Inline처럼 동작

따라서 Array는 inline 저장되어도 성능상 큰 이득은 없습니다.

답: 아니요! Inline 저장 ≠ Static Dispatch입니다.

Inline 저장 (≤ 24 bytes):
• 메모리 할당 방식 (힙 할당 없음)
• 캐시 효율성에만 영향
• → 메모리 성능 개선 ✅

Static Dispatch:
• 메서드 호출 방식 (컴파일 타임 결정)
• 타입에 따라 결정됨 (Struct, final class, Generic)
• → 메서드 호출 성능 개선 ✅

중요: any Protocol은 값이 inline 저장되어도, 메서드 호출은 여전히 PWT를 통한 Dynamic Dispatch입니다!

let drawable: any Drawable = Point()
→ Point는 inline 저장됨 (메모리 빠름)
→ 하지만 drawable.draw()는 Dynamic Dispatch (메서드 호출 느림)

답: any 타입/프로토콜을 따르는 구현체를 담는 메모리 구조입니다.

구성 (총 40 bytes):
• Value Buffer (24B): 실제 값 저장 (작으면 inline, 크면 힙 포인터)
• VWT pointer (8B): 복사/삭제 등 메모리 관리 방법
• PWT pointer (8B): 프로토콜 메서드들의 주소

┌─────────────────────────────────────┐
│  Value Buffer (24 bytes)            │
├─────────────────────────────────────┤
│  VWT Pointer (8 bytes)              │
├─────────────────────────────────────┤
│  PWT Pointer (8 bytes)              │
└─────────────────────────────────────┘

답: 테이블의 개수가 다르게 생성됩니다.

VWT - 타입마다 1개:
"이 타입을 어떻게 복사/삭제하나"만 알면 됨
→ Circle용 VWT 1개, Square용 VWT 1개

PWT - (타입, 프로토콜) 조합마다 1개:
"이 타입이 이 프로토콜 메서드를 어디서 구현했나"
→ Circle+Drawable PWT, Circle+Printable PWT, Square+Drawable PWT

// Circle이 Drawable, Printable 채택 시
Circle용 VWT: 1개 (복사/삭제 방법)
Circle+Drawable PWT: 1개 (draw 주소)
Circle+Printable PWT: 1개 (print 주소)

답: 네, 맞습니다! ✅

struct Circle: Drawable, Printable { ... }

// PWT 2개 생성됨:
┌─────────────────────────────┐
│ Circle + Drawable PWT       │  ← draw() 주소
└─────────────────────────────┘

┌─────────────────────────────┐
│ Circle + Printable PWT      │  ← print() 주소
└─────────────────────────────┘

답: Generic 함수 호출 시 PWT가 파라미터로 함께 전달됩니다.

func render<T: Drawable>(_ item: T) {
    item.draw()
}

// 컴파일러가 내부적으로 변환:
func render(_ item: T, pwt: Drawable_PWT, vwt: T_VWT) {
    pwt.draw(item)  // PWT를 통해 draw 호출
}

// 호출 시:
render(Circle())  // Circle + Drawable PWT 전달
render(Square())  // Square + Drawable PWT 전달

답: 네, 둘 다 PWT를 사용하지만 Generic이 더 빠릅니다!

any Drawable:
• Value Buffer에 값 복사 (boxing)
• 큰 값 (>24B)은 힙 할당 필요
• 40바이트 컨테이너 전체를 넘김

<T: Drawable> (Generic):
• 값 그대로 전달 (boxing 없음)
• 힙 할당 없음
• Specialization 가능 (인라인)

핵심: PWT 사용 여부가 아니라 Existential Container의 boxing 오버헤드가 성능 차이의 원인!

답: 아니요! 인라인은 컴파일 타임 최적화입니다.

인라인 = 함수 호출을 함수 본문으로 대체

// 원본 코드
func square(_ x: Int) -> Int {
    return x * x
}
let result = square(5)

// 컴파일러가 인라인 적용 후
let result = 5 * 5  // 함수 호출 자체가 사라짐

답: 아니요! PWT는 데이터 영역(Data Segment)에 있습니다.

┌─────────────────────────────────┐
│         Code Segment            │  ← 실제 함수 코드
│  Circle.draw: 0x1000            │
├─────────────────────────────────┤
│         Data Segment            │  ← PWT, VWT 테이블들
│  Circle+Drawable PWT: 0x5000    │
│    └─ draw → 0x1000 (포인터)    │
├─────────────────────────────────┤
│         Stack / Heap            │  ← 실제 값들
└─────────────────────────────────┘

답: 맞습니다! 구조가 거의 동일합니다.

공통점:
• 둘 다 Data Segment에 저장
• 둘 다 Code Segment의 함수 주소를 가리킴
• 둘 다 함수 포인터 테이블

차이점:

답: 아니요! 함수 본문을 볼 수 있어야 합니다.

Specialization = 함수 복제
컴파일러가 Generic 함수를 타입별로 복사하는 것

// 원본
func render<T: Drawable>(_ item: T) {
    item.draw()
}

// Specialization 후 (컴파일러가 복제)
func render_Circle(_ item: Circle) {
    item.draw()  // ← 본문 복사됨
}

답: 기본적으로 Specialization이 안 됩니다.

// 모듈 B
func print<T: Drawable>(_ item: T) {
    item.draw()
}

// 모듈 A에서 호출
import ModuleB
print(Circle())  // ❌ Specialization 불가
                 // → PWT 전달 방식으로 컴파일

답: 두 가지를 구분해야 합니다!

1. Specialization = "T가 뭔지 아는 것"
T = Circle만 알면 → Circle.draw() 주소로 직접 호출 가능

2. 인라인 = "함수 본문을 복사하는 것"
Circle.draw() 본문까지 복사하려면 그 코드가 보여야 함

// 모듈 B에서 print(Circle()) 호출 시:

Specialization 후 생성되는 코드:
func print_Circle(_ item: Circle) {
    item.draw()  // Circle.draw() "직접 호출"
                 // PWT 조회 없음 ✅
                 // draw() 본문 인라인 ❌ (다른 모듈)
}

답: 다른 모듈에 함수 본문을 공개하는 키워드입니다.

// 모듈 B
@inlinable
public func print<T: Drawable>(_ item: T) {
    item.draw()
}

// 모듈 A
import ModuleB
print(Circle())  // ✅ Specialization 가능!

Specialization이 적용되려면:

Specialization 필수 조건:

1. T가 뭔지 알아야 함 ✅ (호출부에서 Circle 전달)
2. 함수 본문을 봐야 함 ✅ (복제할 코드 필요)

→ 둘 다 충족해야 Specialization 가능