질문의 역사.
C++11 이전의 많은 std::string 구현체는 복사 시 문자열 데이터를 인스턴스 간에 공유하기 위해 참조 카운팅(복사 시 쓰기)을 사용하여 복사 시 메모리 사용량을 줄였습니다. 그러나 이러한 접근 방식은 내부 참조 카운트가 수정될 때 동시에 읽기가 이터레이터나 참조의 무효화를 유발할 수 있는 스레드 안전성 문제를 초래했습니다. C++11에서는 const 멤버 함수가 참조나 이터레이터를 무효화하지 않도록 요구함으로써 이 최적화를 명시적으로 금지했고, 짧은 문자열에 대한 힙 할당의 성능 비용을 완화하기 위한 새로운 최적화 전략이 필요했습니다.
문제.
힙 할당은 할당자에서의 동기화 오버헤드와 캐시 지역성 문제로 인해 비쌉니다. JSON 파서나 네트워크 프로토콜 핸들러와 같이 수십억 개의 작은 문자열을 처리하는 애플리케이션의 경우, 5-15 문자 시퀀스를 위한 메모리 할당이 실행 시간의 대부분을 차지합니다. 문제는 std::string 객체 내부에 작은 문자열을 저장하는 것입니다. 이는 일반적으로 64비트 시스템에서 32바이트로 제한되며, ABI 호환성을 깨뜨리거나 표준에서 요구하는 강력한 예외 안전 보장을 위반하지 않도록 해야 합니다.
해결책.
구현체는 일반적으로 저장 버퍼를 위한 세 개의 멤버를 가진 유니온을 사용합니다: char* ptr_는 힙에 할당된 배열을, size_t capacity_는 지역 배열을 위한 char local_buffer_[N]를 나타냅니다. 일반적으로 size_ 멤버의 가장 하위 비트에 인코딩되거나 특정 용량 값을 사용하여 문자열이 "SSO 모드"인지 "힙 모드"인지 결정하는 구분자가 있습니다. size() < SSO_CAPACITY일 때 문자는 local_buffer_에 저장되며, local_buffer_[size()]에 널 종결자가 있어 힙 할당을 완전히 피합니다. 더 큰 문자열의 경우, ptr_는 힙 메모리를 가리키며, local_buffer_는 용량 메타데이터를 저장하거나 사용되지 않을 수 있습니다.
// 개념적 구현 (단순화) class string { union { struct { char* ptr; size_t size; size_t cap; } heap; // cap >= SSO_CAP일 때 활성 struct { char buffer[15]; // 15 chars + null terminator unsigned char size; // 압축된 메타데이터, MSB는 힙을 표시 } sso; // size < 15일 때 활성 } data; bool is_sso() const { return (data.sso.size & 0x80) == 0; } };
수많은 작은 태그(예: "35=D", "150=2")가 포함된 FIX 프로토콜 메시지를 처리하는 고빈도 거래 애플리케이션을 고려하십시오. 초기 구현에서는 각 태그 값을 저장하기 위해 std::string을 사용하여 초당 수백만 번의 힙 할당과 시장 데이터 피드를 병목으로 만드는 심각한 할당자 경쟁을 초래했습니다.
해결책 A: 버퍼에 대한 원시 포인터. 원본 메시지 버퍼에 대한 char* 포인터를 사용하면 할당 오버헤드가 전혀 없고 최대 성능을 제공합니다. 그러나 이 접근 방식은 원본 버퍼가 재사용되거나 문자열 데이터가 여전히 필요할 때 해제될 경우 사용 후 해제 버그를 초래하는 위험한 수명 관리 문제를 도입합니다. 또한 문자열 길이를 수동으로 추적해야 하므로 코드 복잡성 및 오류 발생 가능성이 증가합니다.
해결책 B: 메모리 풀을 갖춘 사용자 정의 할당자. 스레드 로컬 메모리 풀을 구현하면 할당 경쟁을 줄일 수 있지만 할당을 배치합니다. 그러나 이는 상당한 템플릿 복잡성을 추가하거나 코드베이스 전반에 걸쳐 다형적 할당자가 필요합니다. 또한 이는 할당 오버헤드를 완전히 제거하지 못하며, 단지 여러 문자열에 걸쳐 비용을 분산할 뿐입니다.
해결책 C: std::string_view 및 SSO. 읽기 전용 처리를 위해 std::string_view를 활용하면 복사를 피할 수 있으며, 저장된 값에 대해 std::string의 자동 SSO를 활용하면 최소한의 오버헤드로 안전성을 제공합니다. 주요 단점은 문자열이 SSO 임계값(15-22 문자)을 초과할 때 성능 절벽이 발생하여 갑자기 비싼 힙 할당을 유발한다는 점입니다. 또한 작은 문자열을 이동하는 것은 포인터를 전달하는 대신 데이터를 복사하므로 O(1) 이동 시멘틱스를 기대하는 개발자에게 놀라움을 줄 수 있습니다.
팀은 해결책 C를 선택하여 파서를 리팩토링하여 임시 참조에 std::string_view를 사용하고 지속성이 필요할 때만 std::string을 사용했습니다. 이를 통해 일반적인 FIX 메시지에서 힙 할당을 95% 줄여 초당 50,000에서 800,000 메시지로 처리량을 개선하면서 메모리 안전성을 유지했습니다.
왜 SSO를 내부적으로 활용하는 짧은 문자열을 이동할 때 포인터 전달이 아닌 문자 복사가 수행되며, 이는 이동된 객체의 상태에 어떤 영향을 미치는가?
SSO 모드에서는 문자 배열이 std::string 객체 내부에 직접 위치합니다(일반적으로 내부 유니온의 멤버로서). 힙에 할당된 문자열의 경우 이동 생성자가 단순히 char* 포인터를 전달하고 소스를 null로 설정하지만, SSO 문자열을 이동하는 경우에는 원본의 내부 버퍼에서 대상의 내부 버퍼로 문자를 복사해야 합니다. 이는 원본 객체가 파괴되며 그 내부 버퍼도 함께 파괴될 것이기 때문입니다. 따라서 목적지는 곧 파괴될 원본의 메모리를 가리킬 수 없습니다. 따라서 작은 문자열을 이동하는 것은 O(N) 복잡성을 가지며, 이동된 객체는 유효하지만 불특정한 상태(비어 있지 않음)를 유지하며, 그 원래 문자는 파괴되거나 재할당될 때까지 계속 포함되어 있습니다.
SSO 모드에서 std::string이 c_str() 및 data()가 널 종료 문자 배열을 반환하도록 보장하는 방법은 무엇인가?
구현은 SSO 버퍼가 최대 SSO 용량보다 항상 한 바이트 더 크도록 보장합니다(예: 15자 문자열의 경우 총 16바이트). N 길이의 문자열(여기서 N < SSO_CAPACITY)을 저장할 때, 구현은 지역 버퍼의 위치 N에 널 종결자를 작성합니다. SSO 모드일 때 data() 및 c_str() 메서드는 힙 포인터가 아닌 이 지역 버퍼의 시작을 가리키는 포인터를 반환합니다. 이는 추가 할당 없이 널 종료를 보장하며, c_str()가 null-terminated 문자열에 대한 const char*를 반환하고, C++11부터 data()도 null-terminated 배열을 가리키도록 하는 표준 요구 사항을 충족합니다.
왜 비어 있는 std::string의 capacity()가 서로 다른 표준 라이브러리 구현(예: 15와 22) 간에 다를 수 있으며, 이는 서로 다른 표준 라이브러리 버전을 혼합할 때 어떤 ABI 영향을 미치는가?
SSO 버퍼 크기는 구현 세부 사항입니다(**libc++**는 일반적으로 64비트 시스템에서 정렬을 활용하여 22자를 사용하고, **libstdc++**는 15자를 사용합니다). 이 크기는 구현이 std::string 객체 레이아웃 내에서 지역 버퍼와 함께 크기/용량 메타데이터를 어떻게 포장하는지에 따라 달라집니다(일반적으로 총 32바이트). 이것이 표준화되지 않았기 때문에 서로 다른 표준 라이브러리 구현으로 컴파일된 바이너리를 혼합하면 (예: GCC로 컴파일된 라이브러리에서 Clang으로 컴파일된 애플리케이션으로 std::string 전달) 메모리 레이아웃의 비호환성으로 인해 정의되지 않은 동작이 발생합니다. 후보자들은 종종 std::string이 표준 ABI를 가지고 있다고 가정하지만, 이는 라이브러리 경계를 넘어 가장 이식성이 떨어지는 유형 중 하나입니다.