Swift는 여분 거주자 활용(extra inhabitant utilization) 또는 여유 비트 패킹(spare bit packing)이라는 컴파일러 최적화를 사용하여 Optional의 none 경우에 대한 저장소 오버헤드를 제거합니다. 참조 타입(클래스, 클로저, AnyObject)의 경우, 기본 포인터 표현에는 유효한 객체 참조가 아닌 null 주소(0x0)가 포함되어 있습니다; Swift는 이 null 포인터를 Optional.none을 나타내는 데 재사용하고, 모든 비-null 포인터는 Optional.some을 나타냅니다. 여러 페이로드를 가진 일반 열거형으로 확장할 때, 컴파일러는 모든 연관 값 타입의 비트 패턴을 분석하여 공통적으로 사용되지 않는 값(여유 비트)을 식별합니다. 만약 모든 페이로드 타입이 경우 수를 인코딩하는 데 필요한 여유 비트를 공유하면, 열거형은 그 비트 내에 경우 식별자를 저장합니다; 그렇지 않으면 별도의 태그 바이트 또는 워드를 추가합니다.
실시간 3D 렌더링 엔진의 장면 그래프를 설계하는 동안 팀은 200만 개의 장면 노드에 대한 선택적 부모 참조를 저장해야 했습니다. 각 노드는 클래스 인스턴스였으며, 계층 구조는 부모가 없는 루트 노드를 표현하기 위해 Optional<Node>를 요구했습니다.
해결책 A: 평행 불리언 배열.
팀은 부모 존재를 나타내기 위해 ContiguousArray<Node>와 함께 별도의 ContiguousArray<Bool>을 유지하는 것을 고려했습니다.
장점: 명시적 제어, 언어 독립적 패턴.
단점: 두 개의 분리된 메모리 영역에 접근하여 캐시 지역성이 파괴되었습니다; 메모리 오버헤드가 2MB 증가했습니다 (불리언당 1바이트, 정렬을 위해 패딩); 트리를 구조화하는 동안 동기화 복잡성이 발생합니다.
해결책 B: 센티널 노드 패턴.
부모가 없는 경우를 나타내기 위한 전역 싱글톤 "null node" 인스턴스를 사용하는 것입니다.
장점: 단일 포인터 저장소, 선택적 오버헤드 없음.
단점: 타입 안정성을 위반합니다; 컴파일러는 센티널에 대한 우발적인 작업을 방지할 수 없습니다; 코드베이스 전반에 걸쳐 방어적 검사가 필요합니다; 센티널이 실제 노드에 대한 참조를 보유하는 경우 참조 사이클이 발생합니다.
해결책 C: 네이티브 Swift Optional.
노드 구조체 내에서 직접 Optional<Node>를 채택합니다.
장점: 완전한 컴파일 타임 안전성, 관용적인 Swift 문법, Optional이 none에 대해 null 포인터 표현을 사용하므로 메모리 오버헤드가 없습니다.
단점: 이 최적화가 참조 타입에만 적용된다는 것을 이해해야 합니다; Int와 같은 값 타입은 패딩이 발생합니다.
팀은 해결책 C를 선택했습니다. Node가 클래스였기 때문에 Optional 래퍼가 인스턴스 크기에 바이트를 추가하지 않았습니다. 결과적으로 평행 불리언 접근 방식과 비교하여 약 16MB의 메모리 감소가 있었으며(불리언 저장소와 관련 정렬 패딩을 모두 제거), 후속 리팩토링 중 null 역참조 충돌 한 가지 전체 클래스를 제거하는 컴파일 타임 보장을 얻었습니다.
왜 Optional<Int>는 일반적으로 Int보다 더 많은 메모리를 차지하는 반면, Optional<AnyObject>는 AnyObject와 동일한 공간을 차지하는가?
Int는 숫자 범위(-2^63에서 2^63-1까지)를 나타내기 위해 가능한 모든 비트 패턴을 사용하는 64비트 2의 보수 정수로서, Optional 식별자가 사용할 수 있는 유효하지 않은 비트 패턴(여분 거주자)을 남기지 않습니다. 결과적으로, 컴파일러는 선택적이 some인지 none인지 저장하기 위해 별도의 바이트(또는 정렬으로 인해 워드)를 추가해야 합니다. 반면에, AnyObject(및 모든 클래스 참조)는 모든 비트가 0인 패턴(null)이 객체 주소로서 보장된 유효하지 않기 때문에, Optional은 none 케이스를 나타내기 위해 이 null 표현을 주장하며 추가 저장소가 필요하지 않습니다.
T가 클래스일 때 Optional<Optional<T>>의 "부재"에 대한 구분된 기계 수준 표현이 몇 개 존재하며, 이것이 동등성에 왜 중요한가?
두 개의 구분된 표현이 존재합니다: 외부의 .none (외부 수준의 null 포인터)과 .some(.none) (내부 null을 가리키는 유효한 외부 포인터). 내부 Optional은 이미 자신의 비어있음을 나타내기 위해 null 포인터 값을 소비하므로, 외부 Optional은 포인터 값만으로는 자신의 none을 내부의 none을 포함하는 .some과 구별할 수 없습니다. 따라서 외부 레이어는 별도의 태그 비트가 필요하며 두 개념적 "nil" 상태는 같지 않습니다 (Optional(Optional.none) != Optional.none). 이 구별은 제네릭 API에서 반환되는 중첩 선택적을 다룰 때 매우 중요하며, JSON 디코딩 시 누락된 키가 외부 nil을 생산하고 null 값이 내부 nil을 생성합니다.
여러 페이로드 케이스를 가진 열거형을 정의할 때, 예를 들어 case integer(Int), case boolean(Bool)에서, 컴파일러가 별도의 태그 바이트를 저장하는지 페이로드 내에 경우 식별자를 포함하는지는 무엇에 따라 결정되는가?
컴파일러는 연관 값 타입의 여유 비트 분석을 수행합니다. Bool은 가장 오른쪽 비트만 사용하므로 7개의 비트를 여유로 남깁니다. 모든 케이스의 페이로드가 각 케이스를 고유하게 식별할 수 있는 충분한 여유 비트를 제공한다면 (예: 동일한 null 여분 거주자를 공유하는 여러 클래스 참조), 열거형은 해당 사용되지 않는 비트에 케이스 인덱스를 패킹할 수 있습니다. 그러나 Int와 Bool은 분리된 여유 비트 패턴을 가지고 있습니다(Int는 여유 비트가 없음), 컴파일러는 정수형과 불리언을 구별하기 위해 별도의 태그 바이트(또는 워드)를 할당하여 열거형의 크기를 최대 페이로드 크기 이상으로 증가시킵니다.