map.emplace(key, value_args...)와 같은 인수로 std::map::emplace를 호출할 때, C++ 표준에서는 임플리멘테이션이 키의 유일성을 검사하기 전에 임시 std::pair<const Key, T>(또는 그 노드에 해당하는 것)를 생성해야 한다고 요구합니다. 키가 이미 존재하는 경우, 이 노드는 즉시 폐기되며, 이는 매핑된 값 T의 비싼 생성이 낭비됨을 의미합니다.
std::piecewise_construct 태그는 이 동작을 변경하여 컨테이너에 후속 두 개의 튜플 인수를 각각 키 및 값 생성자에 대한 인수 목록으로 취급하도록 신호를 보냅니다. 생성자 인수를 std::forward_as_tuple로 래핑함으로써, 컨테이너는 매핑된 값의 실제 인스턴스화를 새로 할당된 노드 안에서만 지연시키고, 키가 고유하다고 확인되었을 경우에만 진행합니다. 이는 값이 정확히 한 번, 최종 메모리 위치에서 생성되고, 삽입이 실패할 경우에는 결코 생성되지 않도록 보장합니다.
고주파 거래 플랫폼에서 **std::map<OrderID, Order>**에 역직렬화된 Order 객체(벡터와 문자열이 포함된 큰 구조체)를 캐시해야 했습니다. 초기 구현은 orders.emplace(id, DeserializeOrder(buffer))를 사용했습니다. 프로파일링 결과, 시장 폭발 시 중복 ID에 대해 Order 객체를 생성하는 데 CPU 시간의 15%가 낭비된다는 것을 발견했습니다. 이 객체들은 맵의 거부 로직에 의해 즉시 폐기되었습니다.
해결책 1: 확인 후 삽입. 우선 if (orders.find(id) == orders.end())를 명시적으로 체크한 후 emplace를 호출하는 것을 고려했습니다. 이는 불필요한 생성은 피할 수 있었지만, 하나의 검색과 또 하나의 삽입을 위한 두 개의 트리 탐색이 필요하여 비교 비용이 두 배로 증가하고 캐시 지역성이 나빠졌습니다.
해결책 2: 수동 노드 추출. orders.extract(id)를 사용하여 수동으로 std::map::node_type을 생성하고 비어 있는 경우 재삽입하는 방법도 검토했습니다. 그러나 이 경우 노드를 채우기 위해 매핑 외부에서 Order를 미리 생성해야 해서 원래의 문제를 다시 유발했습니다.
해결책 3: std::piecewise_construct. orders.emplace(std::piecewise_construct, std::forward_as_tuple(id), std::forward_as_tuple(buffer))를 채택했습니다. 이는 노드 삽입이 보장될 때까지 역직렬화를 지연시켰습니다. 이로 인해 성능 문제가 해결되었으나, 인수 수명과 관련하여 구문이 장황하고 오류가 발생하기 쉬웠습니다.
선택한 접근 방식 및 결과: 궁극적으로 우리는 C++17로 마이그레이션하고 orders.try_emplace(id, buffer)를 사용했습니다. 이는 성공적인 삽입 시에만 Order가 생성되도록 보장하는 효율성을 제공하며, 구문이 간결하고 덩어리가 유효할 위험을 줄였습니다. 시스템 대기 시간이 최대 부하 시 12% 감소했습니다.
std::piecewise_construct를 위한 인수 준비 시 왜 std::forward_as_tuple을 사용해야 하며, std::make_tuple을 사용해서는 안 되는가?
std::make_tuple는 그 인수를 분해하여 튜플을 생성합니다; 이는 값을 튜플 저장소에 복사하거나 이동합니다. 만약 매핑된 타입이 복사 불가능하거나 큰 객체를 전달하는 경우, make_tuple은 컴파일에 실패하거나 불필요한 복사 오버헤드를 유발합니다. std::forward_as_tuple는 원래 값 범주를 보존하는 참조의 튜플을 생성하여, 중간 복사 없이 객체의 생성자에 직접 완벽히 전달합니다.
std::piecewise_construct를 사용할 때, std::forward_as_tuple로 래핑된 참조가 삽입 완료 시까지 유효해야 하는 이유는 무엇인가?
forward_as_tuple는 전달된 임시 객체의 수명을 연장하지 않으며, 단지 참조를 캡처합니다. 만약 map.emplace(std::piecewise_construct, std::forward_as_tuple(CreateTempKey()), std::forward_as_tuple(args...))와 같이 작성하면, CreateTempKey()가 반환한 임시 객체는 전체 표현식의 끝에서 파괴되어 emplace가 내부적으로 노드를 생성하려고 시도하기 전에 없어집니다. 이는 튜플이 덩어리 참조를 보유하게 되어, 생성자가 키에 접근할 때 정의되지 않은 동작을 초래합니다.
std::map::try_emplace가 키 자체를 처리하는 데 있어 emplace + piecewise_construct 관용구와 어떻게 다른가?
piecewise_construct는 키와 값의 생성 지연을 모두 할 수 있지만, try_emplace는 열린 인수의 생성 인수와 키를 명시적으로 분리합니다. try_emplace는 키를 참조(또는 값)로 받아들이고, 삽입이 성공할 경우에만 나머지 인수를 매핑된 타입의 생성자로 전달합니다. 이는 try_emplace가 여러 인수로 키를 제자리에서 생성할 수 없으며, 키 객체가 이미 존재하거나 단일 인수로부터 생성될 수 있어야 함을 의미합니다. 반면, piecewise_construct는 두 구성 요소의 생성을 지연시킬 수 있습니다. 그러나 try_emplace는 수동 튜플 관리의 구문적 장황함과 수명 위험을 제거합니다.