absl::Cord vs std::string — 선택 기준과 메모리 프로파일

#한 줄 요약

std::string은 연속 buffer, 자주 mutation, 작은 크기에 강하다. absl::Cord는 공유, 큰 크기, 잘라내기·합치기에 강하다. 두 타입의 cost model이 다르므로 선택은 데이터 lifecycle에 따라 정한다.

#한 장 정리

다음 표가 결정의 90%를 정한다.

#메모리 프로파일 비교

#std::string

libstdc++ x86_64 기준 sizeof = 32 byte.

1
+-------------------+
2
| data_*  (8B)      |  → heap 또는 inline buf
3
| size_   (8B)      |
4
| capacity_ (8B)    |
5
| inline_buf_[15]   |  → 작은 문자열은 여기
6
| +1 NUL            |
7
+-------------------+

SSO 임계치를 넘으면 연속 heap buffer 한 개에 모든 byte. capacity 부족 시 전체 재할당 + memcpy.

#absl::Cord

sizeof = 16 byte (inline rep) 또는 16 byte (tree rep, root pointer만).

1
Inline (size ≤ 15B):
2
+-------------------+
3
| inline_buf[15]    |
4
| tag (LSB=0)       |
5
+-------------------+
6

7
Tree (size > 15B):
8
+-------------------+
9
| CordRep* tree     |
10
| reserved          |
11
| tag (LSB=1)       |
12
+-------------------+

큰 데이터는 외부 tree에 산다. tree 자체는 BTREE 노드 + leaf chunk들로 구성. 각 chunk는 refcount + 4KB FLAT 또는 외부 view.

#메모리 풋프린트 차이

10MB 문자열을 5개의 컴포넌트가 공유하는 경우:

1
std::string 5개 + 각자 복사:
2
  10MB × 5 = 50MB
3

4
Cord 5개 + refcount 공유:
5
  10MB × 1 + (16B × 5) = 10.00008MB

거대 데이터의 공유 빈도가 높을수록 격차가 크다. 반대로 5개 컴포넌트가 각자 mutation을 한다면 결국 copy-on-write 비용을 부담해야 한다 (Cord의 mutation은 path 위 노드를 자체 복사).

#append/erase 비용 모델

std::string은 단순한 연속 buffer라 작은 mutation이 매우 빠르다. 중간 삽입이나 prepend는 비효율적. Cord는 위치 무관 O(log n)이지만 작은 mutation에도 tree 조작 비용을 항상 낸다.

#사용 사례별 권장

#1. 짧은 식별자, key

1
absl::flat_hash_map<std::string, User> users;   // key는 std::string

hash map key는 == 비교가 잦고 메모리 locality가 필수. Cord는 불리.

#2. 큰 RPC payload

1
class RpcResponse {
2
  absl::Cord payload_;   // 외부에서 받아 그대로 전달
3
};

받은 데이터를 내가 변형하지 않고 다른 컴포넌트로 흘려보낼 때 Cord가 적격. zero-copy 체인이 길수록 이득.

#3. log buffer 누적

1
// 회피 — 큰 string에 매번 append
2
std::string log;
3
for (auto& msg : msgs) log += msg;   // 후반에 reallocation 폭발
4

5
// Good — Cord, 또는 std::string에 reserve
6
absl::Cord log;
7
for (auto& msg : msgs) log.Append(msg);

reserve로 미리 잡을 수 있다면 std::string도 OK. 크기 예측이 어려우면 Cord.

#4. file mmap 흡수

1
void* p = ::mmap(...);
2
absl::Cord c = absl::MakeCordFromExternal(
3
    absl::string_view(static_cast<char*>(p), len),
4
    [fd, p, len](absl::string_view) { ::munmap(p, len); ::close(fd); });

mmap 영역을 그대로 Cord로 만든다. 평탄화 복사 없음. std::string에서는 불가능한 패턴.

#5. 직렬화 buffer

protobuf의 SerializeToCord()는 Cord를 직접 만든다. 큰 메시지에서 alloc 횟수가 1/10 수준으로 줄어든다.

#잘못된 선택의 비용

#작은 데이터에 Cord

1
absl::Cord short_name("hello");

inline rep에 들어가긴 한다(15 byte까지). 하지만 API 시그니처가 const Cord&라면 호출자가 임시 Cord를 만들어야 한다. std::string/string_view로 받았으면 그냥 view 한 번이면 끝났을 일.

#큰 데이터에 std::string 반복 prepend

1
std::string buf;
2
for (auto& chunk : reverse_chunks) {
3
  buf = chunk + buf;   // O(n^2) 누적
4
}

prepend는 std::string의 약점. 이런 패턴이 보이면 Cord 후보.

#Cord에 random access

1
absl::Cord c = ReadLargeFile();
2
for (size_t i = 0; i < c.size(); ++i) {
3
  if (c[i] == '\n') ++lines;   // O(n log n)
4
}

chunk 순회로 바꾸면 O(n).

1
size_t lines = 0;
2
for (absl::string_view ch : c.Chunks()) {
3
  lines += std::count(ch.begin(), ch.end(), '\n');
4
}

#코드 리뷰 포인트

1. payload 타입 선택 근거를 PR에 적는다

std::string/Cord/string_view 중 선택은 데이터 흐름에 달려 있다. 리뷰어가 의도를 추측하지 않게 한 줄 주석.

1
// payload는 외부에서 mmap으로 받아 그대로 RPC로 흘림 → Cord
2
absl::Cord payload_;

2. 함수 시그니처 const Cord& vs absl::string_view

1
// 호출자가 Cord 들고 있을 때만
2
void Process(const absl::Cord& body);
3

4
// 더 일반적 — string_view, std::string, char*도 받음
5
void Process(absl::string_view body);

Cord 전용 API는 Cord의 zero-copy 이점을 살릴 때에만 정당하다. 단순 read-only면 string_view가 호출 측 유연성이 크다.

3. 변환 횟수 계측

Cord ↔ std::string 변환이 코드 경로에 반복되면 Cord의 이점이 사라진다. 변환 1회 = 전체 데이터 복사.

1
// 회피 — 경로 안에서 양방향 변환
2
absl::Cord c = LoadFromDisk();
3
std::string s(c);                  // 전체 복사
4
auto result = Process(s);
5
absl::Cord out(result);            // 또 전체 복사
6
return out;
7

8
// Good — Cord로 일관
9
absl::Cord c = LoadFromDisk();
10
return ProcessCord(c);

4. 함수 반환 타입의 영향

1
// std::string 반환 — 호출자가 immediate 소비 가정
2
std::string MakeReport();
3

4
// Cord 반환 — 호출자가 전달/저장 가정
5
absl::Cord MakeReport();

반환 타입이 그 함수의 결과 데이터 lifecycle에 대한 시그널이다. Cord 반환은 “쪼개거나 전달할 거다”라는 의도, std::string 반환은 “바로 사용할 거다”라는 의도.

#마이그레이션 체크리스트

기존 std::string 코드를 Cord로 옮길지 결정하는 빠른 체크.

합산 점수 4 이상이면 Cord 검토. 3 이하면 std::string 유지.

#정리

• 결정은 크기·공유·mutation 패턴의 세 축으로.
• 작은 데이터·잦은 mutation·random access → std::string.
• 큰 데이터·공유·잘라내기 → Cord.
• hash key·짧은 식별자는 거의 항상 std::string.
• 변환 횟수를 의식하고 한 데이터의 경로 전체에 일관된 타입을 쓴다.

#다음 편

Part 16에서 디버깅·CRC·프로파일링 도구를 본다. Part 16-01 — Stacktrace와 Symbolize.

#관련 항목

• Part 16-01 — Stacktrace / Symbolize
• Part 15-01 — Cord
• Part 15-02 — charconv
• Part 4-01 — string_view
• Folly Part 5-02 — IOBuf